9.5.2 Entries and Accept Statements
Proof: This follows from the BNF.
Reason: An entry family can never implement
something, so allowing an indicator is felt by the majority of the ARG
to be redundant.
Name Resolution Rules
The only declarations that occur
immediately within the declarative region of an accept_statement
are those for its formal parameters.
in a task declaration shall not contain a specification for an access
parameter (see 3.10
parameters for task entries would require a complex implementation. For
task T is
entry E(Z : access Integer); -- Illegal!
task body T is
type A is access all Integer;
X : A;
Int : aliased Integer;
task body Inner is
accept E(Z : access Integer) do
X := A(Z); -- Accessibility_Check
Implementing the Accessibility_Check inside
for E is difficult, since one does not know whether the entry caller
is calling from inside the immediately enclosing declare block or from
outside it. This means that the lexical nesting level associated with
the designated object is not sufficient to determine whether the Accessibility_Check
should pass or fail.
Note that such problems do not arise with protected
entries, because entry_bodies
are always nested
immediately within the protected_body
they cannot be further nested as can accept_statement
nor can they be called from within the protected_body
(since no entry calls are permitted inside a protected_body
if the overriding_indicator
is not overriding
, then the entry shall not implement any inherited
In addition to the places where
Legality Rules normally apply (see 12.3
these rules also apply in the private part of an instance of a generic
These rules are subtly different
than those for subprograms (see 8.3.1
there cannot be “late” inheritance of primitives from interfaces.
Hidden (that is, private) interfaces are prohibited explicitly (see 7.3
as are hidden primitive operations (as private operations of public abstract
types are prohibited — see 3.9.3
are required to be immediately within the enclosing task_body
(as opposed to being in a nested subprogram) to ensure that a nested
task does not attempt to accept the entry of its enclosing task. We considered
relaxing this restriction, either by making the check a run-time check,
or by allowing a nested task to accept an entry of its enclosing task.
However, neither change seemed to provide sufficient benefit to justify
the additional implementation burden.
for the same entry (or entry family) are prohibited to ensure that there
is no ambiguity in the resolution of an expanded name for a formal parameter
of the entry. This could be relaxed by allowing the inner one to hide
the outer one from all visibility, but again the small added benefit
didn't seem to justify making the change for Ada 95.
To be honest:
If the implementation supports it, the entry body can be imported (using
aspect Import, see B.1
), in which case no explicit
The above applies only to
protected entries, which are the only ones completed with entry_bodies
Task entries have corresponding accept_statement
instead of having entry_bodies
, and we do
not consider an accept_statement
to be a “completion,” because a task entry_declaration
is allowed to have zero, one, or more than one corresponding accept_statement
Discussion: Note that access parameters
are not allowed for task entries (see above).
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
which entry of the family was called.
The elaboration of the declaration of a protected subprogram has no effect,
as specified in subclause 6.1
. The default
initialization of an object of a task or protected type is covered in
[The actions to be performed when an entry is called
are specified by the corresponding accept_statement
(if any) for an entry of a task unit, and by the corresponding entry_body
for an entry of a protected unit.]
The interaction between a task
that calls an entry and an accepting task is called a rendezvous.
For the execution of an accept_statement
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.
of the accept_statement
is then blocked until a caller of the corresponding entry is selected
), 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. Execution
of the rendezvous consists of the execution
of the handled_sequence_of_statements
performance of any postcondition or type invariant
checks associated with the entry, and any initialization or finalization
associated with these checks, as described in 6.1.1
and 7.3.2. After execution of the rendezvous,
completes and is left. [The two tasks then proceed
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
This is in addition to
propagating it to the construct containing the accept_statement
In other words, for a rendezvous, the raising splits in two, and continues
concurrently in both tasks.
The caller gets a new occurrence; this isn't
Execution of the rendezvous does not include any
checks associated with parameter copy back or any post-call subtype predicate
check for a parameter which is passed by reference. These checks are
performed by the caller after the execution of the rendezvous.
This paragraph was
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.]
24 A task entry has corresponding accept_statements
(zero or more), whereas a protected entry has a corresponding entry_body
A single entry overloads
a subprogram, an enumeration literal, or another single entry if they
have the same defining_identifier
Overloading is not allowed for entry family names. A single entry or
an entry of an entry family can be renamed as a procedure as explained
27 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
Examples of entry
entry Read(V : out Item);
entry Request(Level)(D : Item); -- a family of entries
Examples of accept
accept Read(V : out Item) do
V := Local_Item;
accept Request(Low)(D : Item) do
Extensions to Ada 83
Wording Changes from Ada 95
Extensions to Ada 2005
Extensions to Ada 2012
Named entry indexes now can have an aspect_specification,
allowing the specification of (implementation-defined) aspects for a
named entry index.
Wording Changes from Ada 2012
Correction: Clarified that postcondition
and invariant checks are clearly part of the rendezvous for an entry
call. 6.1.1 already said this, so the intent
was clear and this is not an inconsistency.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe