9.5.2 Entries and Accept Statements
1
Entry_declarations, with
the corresponding entry_bodies or accept_statements,
are used to define potentially queued operations on tasks and protected
objects.
Syntax
2/2
entry_declaration ::=
[
overriding_indicator]
entry defining_identifier [(
discrete_subtype_definition)]
parameter_profile;
3
accept_statement ::=
accept entry_direct_name [(
entry_index)]
parameter_profile [
do
handled_sequence_of_statements
end [
entry_identifier]];
4
entry_index ::= expression
5
entry_body ::=
entry defining_identifier entry_body_formal_part entry_barrier is
declarative_part
begin
handled_sequence_of_statements
end [
entry_identifier];
6
entry_body_formal_part ::= [(
entry_index_specification)]
parameter_profile
7
entry_barrier ::= when condition
8
entry_index_specification ::= for defining_identifier in discrete_subtype_definition
9
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.
10
An entry_declaration
is allowed only in a protected or task declaration.
10.1/2
An overriding_indicator
is not allowed in an entry_declaration that
includes a discrete_subtype_definition.
Name Resolution Rules
11
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.
12
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
4.1.3); the
selector_name
of the
selected_component has to be the
identifier
for some formal parameter of the
accept_statement.
Legality Rules
13
An
entry_declaration in
a task declaration shall not contain a specification for an access parameter
(see
3.10).
13.1/2
If an entry_declaration
has an overriding_indicator, then at the point
of the declaration:
13.2/2
- if the overriding_indicator
is overriding, then the entry shall implement an inherited subprogram;
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.
14
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.
15
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.
16
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.
17
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
6.3.1).
18
A name that denotes a formal parameter of an entry_body
is not allowed within the entry_barrier of
the entry_body.
Static Semantics
19
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
6.2).
20
An
entry_declaration with a
discrete_subtype_definition
(see
3.6) 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.
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.
Dynamic Semantics
22/1
The elaboration of an
entry_declaration
for an entry family consists of the elaboration of the
discrete_subtype_definition,
as described in
3.8. The elaboration of an
entry_declaration for a single entry has no
effect.
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
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
9.5.3),
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.
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
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
9.5.3).
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
9.5.4).
27
23 A task entry has corresponding accept_statements
(zero or more), whereas a protected entry has a corresponding entry_body
(exactly one).
28
24 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.
29/2
25 A return statement (see
6.5)
or a
requeue_statement (see
9.5.4)
may be used to complete the execution of an
accept_statement
or an
entry_body.
30
26 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;
Sponsored by Ada-Europe