- (1)
- Entry_declarations, with the corresponding entry_bodies or accept_statements, are used to define potentially queued operations on tasks and
protected objects.
(2)
entry_declaration ::=
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.
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).
- (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)
- For the elaboration of an entry_declaration for an entry family, if the
discrete_subtype_definition contains no per-object expressions (see
3.8), 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.
- (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)
(22) A task entry has corresponding accept_statements (zero or more),
whereas a protected entry has a corresponding entry_body (exactly one).
- (28)
(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.
- (29)
(24) 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)
(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.
- (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;
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12
| 
| 
| 
| 