9.5.2 Entries and Accept Statements
1
Syntax
2/3
3
3.a
4
5
5.a/2
6
7
8
9
10
10.a
Proof: This follows from the BNF.
10.1/2
10.a.1/2
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
11
12
12.a
Proof: The only declarations that occur
immediately within the declarative region of an
accept_statement
are those for its formal parameters.
Legality Rules
13
An
entry_declaration
in a task declaration shall not contain a specification for an access
parameter (see
3.10).
13.a
Reason: Access
parameters for task entries would require a complex implementation. For
example:
13.b
task T is
entry E(Z : access Integer); -- Illegal!
end T;
13.c
task body T is
begin
declare
type A is access all Integer;
X : A;
Int : aliased Integer;
task Inner;
task body Inner is
begin
T.E(Int'Access);
end Inner;
begin
accept E(Z : access Integer) do
X := A(Z); -- Accessibility_Check
end E;
end;
end T;
13.d
Implementing the Accessibility_Check inside
the
accept_statement
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.
13.e
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_statements,
nor can they be called from within the
protected_body
(since no entry calls are permitted inside a
protected_body).
13.1/2
13.2/2
13.3/2
if the overriding_indicator
is not overriding, then the entry shall not implement any inherited
subprogram.
13.4/2
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
unit.
13.f/2
Discussion: These
rules are subtly different than those for subprograms (see 8.3.1)
because 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).
14
15
15.a
Reason: Accept_statements
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.
15.b
Nested
accept_statements
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.
15.c
16
16.a
16.b/3
To be honest: {
AI05-0229-1}
If The completion
can be a pragma
Import, if the implementation supports it
,
the entry body can be imported (using aspect Import, see B.1),
in which case no explicit entry_body
is allowed.
16.c
Discussion: The above applies only to
protected entries, which are the only ones completed with
entry_bodies.
Task entries have corresponding
accept_statements
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_statements.
17
18
Static Semantics
19
19.a
Discussion: Note that access parameters
are not allowed for task entries (see above).
20
21
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.
21.a
Dynamic Semantics
22/1
22.a
Discussion: The elaboration of the declaration
of a protected subprogram has no effect, as specified in clause
6.1.
The default initialization of an object of a task or protected type is
covered in
3.3.1.
23
[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.]
24
24.a
Ramification: 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.
24.b
The caller gets a new occurrence; this isn't
considered propagation.
24.c
25
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.]
26
26.a
27
24 A task entry has corresponding accept_statements
(zero or more), whereas a protected entry has a corresponding entry_body
(exactly one).
28
29/2
29.a
29.b
Ramification: 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
in
8.5.4.
30
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.
31
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
32
Examples of entry
declarations:
33
entry Read(V : out Item);
entry Seize;
entry Request(Level)(D : Item); -- a family of entries
34
Examples of accept
statements:
35
accept Shut_Down;
36
accept Read(V : out Item) do
V := Local_Item;
end Read;
37
accept Request(Low)(D : Item) do
...
end Request;
Extensions to Ada 83
37.a
37.b
Wording Changes from Ada 95
37.c/2
37.d/2
Extensions to Ada 2005
37.e/3
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
