Go to the first, previous, next, last section, table of contents.
Entry_declarations, with the corresponding entry_bodies or
accept_statements, are used to define potentially queued operations on
tasks and protected objects.
entry defining_identifier [(discrete_subtype_definition)]
accept entry_direct_name [(entry_index)] parameter_profile
entry_index ::= expression
entry defining_identifier entry_body_formal_part entry_barrier is
entry_barrier ::= when condition
for defining_identifier in discrete_subtype_definition
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.
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
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
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
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.
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.
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
The above interaction between a calling task and an accepting task is
called a rendezvous. After a rendezvous, the two tasks continue their
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.
(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 of entry declarations:
entry Read(V : out Item);
entry Request(Level)(D : Item); -- a family of entries
Examples of accept statements:
accept Read(V : out Item) do
V := Local_Item;
accept Request(Low)(D : Item) do
Go to the first, previous, next, last section, table of contents.