Go to the first, previous, next, last section, table of contents.

9.5.2 Entries and Accept Statements

Entry_declarations, with the corresponding entry_bodies or accept_statements, are used to define potentially queued operations on tasks and protected objects.
Syntax

entry_declaration ::=
   entry defining_identifier [(discrete_subtype_definition)]
     parameter_profile;

accept_statement ::=
   accept entry_direct_name [(entry_index)] parameter_profile
      [do handled_sequence_of_statements
   end [entry_identifier]];

```
entry_index ::= expression
```

entry_body ::=
   entry defining_identifier entry_body_formal_part entry_barrier is
      declarative_part
   begin
      handled_sequence_of_statements
   end [entry_identifier];

entry_body_formal_part ::=
   [(entry_index_specification)] parameter_profile

```
entry_barrier ::= when condition
```
```
entry_index_specification ::=
   for defining_identifier in discrete_subtype_definition
```
1. If an entry_identifier appears at the end of an accept_statement, it shall repeat the entry_direct_name. If an entry_identifier appears at the end of an entry_body, it shall repeat the defining_identifier.
2. An entry_declaration is allowed only in a protected or task declaration.

Name Resolution Rules

In an accept_statement, the expected profile for the entry_direct_name is that of the entry_declaration; the expected type for an entry_index is that of the subtype defined by the discrete_subtype_definition of the corresponding entry_declaration.
Within the handled_sequence_of_statements of an accept_statement, if a selected_component has a prefix that denotes the corresponding entry_declaration, then the entity denoted by the prefix is the accept_statement, and the selected_component is interpreted as an expanded name, See section 4.1.3 Selected Components, the selector_name of the selected_component has to be the identifier for some formal parameter of the accept_statement.
Legality Rules
An entry_declaration in a task declaration shall not contain a specification for an access parameter, See section 3.10 Access Types.
For an accept_statement, the innermost enclosing body shall be a task_body, and the entry_direct_name shall denote an entry_declaration in the corresponding task declaration; the profile of the accept_statement shall conform fully to that of the corresponding entry_declaration. An accept_statement shall have a parenthesized entry_index if and only if the corresponding entry_declaration has a discrete_subtype_definition.
An accept_statement shall not be within another accept_statement that corresponds to the same entry_declaration, nor within an asynchronous_select inner to the enclosing task_body.
An entry_declaration of a protected unit requires a completion, which shall be an entry_body, and every entry_body shall be the completion of an entry_declaration of a protected unit. The profile of the entry_body shall conform fully to that of the corresponding declaration.
An entry_body_formal_part shall have an entry_index_specification if and only if the corresponding entry_declaration has a discrete_subtype_definition. In this case, the discrete_subtype_definitions of the entry_declaration and the entry_index_specification shall fully conform to one another, See section 6.3.1 Conformance Rules.
A name that denotes a formal parameter of an entry_body is not allowed within the entry_barrier of the entry_body.
Static Semantics
The parameter modes defined for parameters in the parameter_profile of an entry_declaration are the same as for a subprogram_declaration and have the same meaning, See section 6.2 Formal Parameter Modes.
An entry_declaration with a discrete_subtype_definition, See section 3.6 Array Types, declares a family of distinct entries having the same profile, with one such entry for each value of the entry index subtype defined by the discrete_subtype_definition. A name for an entry of a family takes the form of an indexed_component, where the prefix denotes the entry_declaration for the family, and the index value identifies the entry within the family. The term single entry is used to refer to any entry other than an entry of an entry family.
In the entry_body for an entry family, the entry_index_specification declares a named constant whose subtype is the entry index subtype defined by the corresponding entry_declaration; the value of the named entry index identifies which entry of the family was called.
Dynamic Semantics
For the elaboration of an entry_declaration for an entry family, if the discrete_subtype_definition contains no per-object expressions, See section 3.8 Record Types, then the discrete_subtype_definition is elaborated. Otherwise, the elaboration of the entry_declaration consists of the evaluation of any expression of the discrete_subtype_definition that is not a per-object expression (or part of one). The elaboration of an entry_declaration for a single entry has no effect.
The actions to be performed when an entry is called are specified by the corresponding accept_statements (if any) for an entry of a task unit, and by the corresponding entry_body for an entry of a protected unit.
For the execution of an accept_statement, the entry_index, if any, is first evaluated and converted to the entry index subtype; this index value identifies which entry of the family is to be accepted. Further execution of the accept_statement is then blocked until a caller of the corresponding entry is selected, See section 9.5.3 Entry Calls, whereupon the handled_sequence_of_statements, if any, of the accept_statement is executed, with the formal parameters associated with the corresponding actual parameters of the selected entry call. Upon completion of the handled_sequence_of_statements, the accept_statement completes and is left. When an exception is propagated from the handled_sequence_of_statements of an accept_statement, the same exception is also raised by the execution of the corresponding entry_call_statement.
The above interaction between a calling task and an accepting task is called a rendezvous. After a rendezvous, the two tasks continue their execution independently.
An entry_body is executed when the condition of the entry_barrier evaluates to True and a caller of the corresponding single entry, or entry of the corresponding entry family, has been selected, See section 9.5.3 Entry Calls. For the execution of the entry_body, the declarative_part of the entry_body is elaborated, and the handled_sequence_of_statements of the body is executed, as for the execution of a subprogram_body. The value of the named entry index, if any, is determined by the value of the entry index specified in the entry_name of the selected entry call (or intermediate requeue_statement -- See section 9.5.4 Requeue Statements.
NOTES
(22) A task entry has corresponding accept_statements (zero or more), whereas a protected entry has a corresponding entry_body (exactly one).
(23) A consequence of the rule regarding the allowed placements of accept_statements is that a task can execute accept_statements only for its own entries.
(24) A return_statement, See section 6.5 Return Statements, or a requeue_statement, See section 9.5.4 Requeue Statements, may be used to complete the execution of an accept_statement or an entry_body.
(25) The condition in the entry_barrier may reference anything visible except the formal parameters of the entry. This includes the entry index (if any), the components (including discriminants) of the protected object, the Count attribute of an entry of that protected object, and data global to the protected unit.
The restriction against referencing the formal parameters within an entry_barrier ensures that all calls of the same entry see the same barrier value. If it is necessary to look at the parameters of an entry call before deciding whether to handle it, the entry_barrier can be "when True" and the caller can be requeued (on some private entry) when its parameters indicate that it cannot be handled immediately.
Examples
Examples of entry declarations:

entry Read(V : out Item);
entry Seize;
entry Request(Level)(D : Item);  --  a family of entries

Examples of accept statements:
```
accept Shut_Down;
```

accept Read(V : out Item) do
   V := Local_Item;
end Read;

accept Request(Low)(D : Item) do
   ...
end Request;

Go to the first, previous, next, last section, table of contents.