9.5.3 Entry Calls
An
entry_call_statement
(an
entry call) can appear in various contexts.
A
simple entry call is a stand-alone statement that represents an
unconditional call on an entry of a target task or a protected object.
Entry calls can also appear as part of
select_statements
(see
9.7).
Syntax
Name Resolution Rules
The
entry_name
given in an
entry_call_statement
shall resolve to denote an entry. The rules for parameter associations
are the same as for subprogram calls (see
6.4
and
6.4.1).
Static Semantics
The
entry_name
of an
entry_call_statement
specifies (explicitly or implicitly) the target object of the call, the
entry or entry family, and the entry index, if any (see
9.5).
Dynamic Semantics
Under
certain circumstances (detailed below), an entry of a task or protected
object is checked to see whether it is
open or
closed:
An entry
of a protected object is open if the
condition
of the
entry_barrier
of the corresponding
entry_body
evaluates to True; otherwise, it is closed.
If the
evaluation of the
condition
propagates an exception, the exception Program_Error is propagated to
all current callers of all entries of the protected object.
For
the execution of an
entry_call_statement,
evaluation of the
name
and of the parameter associations is as for a subprogram call (see
6.4).
The entry call is then
issued: For a call
on an entry of a protected object, a new protected action is started
on the object (see
9.5.1). The named entry
is checked to see if it is open;
if open, the entry
call is said to be
selected immediately, and the execution of
the call proceeds as follows:
For a call on an open entry of a task, the accepting
task becomes ready and continues the execution of the corresponding
accept_statement
(see
9.5.2).
For a call on an open entry of a protected object,
the corresponding
entry_body
is executed (see
9.5.2) as part of the protected
action.
If the
accept_statement
or
entry_body
completes other than by a requeue (see
9.5.4),
return is made to the caller (after servicing the entry queues —
see below); any necessary assigning back of formal to actual parameters
occurs, as for a subprogram call (see
6.4.1);
such assignments take place outside of any protected action.
If the named entry is closed, the entry call is added
to an
entry queue (as part of the protected action, for a call
on a protected entry), and the call remains queued until it is selected
or cancelled;
there is a separate (logical) entry
queue for each entry of a given task or protected object (including each
entry of an entry family).
When
a queued call is
selected, it is removed from its entry queue.
Selecting a queued call from a particular entry queue is called
servicing
the entry queue. An entry with queued calls can be serviced under the
following circumstances:
If after performing, as part of a protected action
on the associated protected object, an operation on the object other
than a call on a protected function, the entry is checked and found to
be open.
If there is at least one call
on a queue corresponding to an open entry, then one such call is selected
according to the
entry queuing policy in effect (see below), and
the corresponding
accept_statement
or
entry_body
is executed as above for an entry call that is selected immediately.
The entry queuing policy controls
selection among queued calls both for task and protected entry queues.
The default entry queuing policy
is to select calls on a given entry queue in order of arrival. If calls
from two or more queues are simultaneously eligible for selection, the
default entry queuing policy does not specify which queue is serviced
first. Other entry queuing policies can be specified by
pragmas
(see
D.4).
For a protected object, the above servicing of entry
queues continues until there are no open entries with queued calls, at
which point the protected action completes.
An attempt can be made to cancel
an entry call upon an abort (see
9.8) and as
part of certain forms of
select_statement
(see
9.7.2,
9.7.3,
and
9.7.4). The cancellation does not take
place until a point (if any) when the call is on some entry queue, and
not protected from cancellation as part of a requeue (see
9.5.4);
at such a point, the call is removed from the entry queue and the call
completes due to the cancellation. The cancellation of a call on an entry
of a protected object is a protected action, and as such cannot take
place while any other protected action is occurring on the protected
object. Like any protected action, it includes servicing of the entry
queues (in case some entry barrier depends on a Count attribute).
A call on an entry of a task
that has already completed its execution raises the exception Tasking_Error
at the point of the call; similarly, this exception is raised at the
point of the call if the called task completes its execution or becomes
abnormal before accepting the call or completing the rendezvous (see
9.8). This applies equally to a simple entry
call and to an entry call as part of a
select_statement.
Implementation Permissions
An implementation may perform the sequence of steps
of a protected action using any thread of control; it need not be that
of the task that started the protected action. If an
entry_body
completes without requeuing, then the corresponding calling task may
be made ready without waiting for the entire protected action to complete.
When the entry of a protected object is checked to
see whether it is open, the implementation need not reevaluate the
condition
of the corresponding
entry_barrier
if no variable or attribute referenced by the
condition
(directly or indirectly) has been altered by the execution (or cancellation)
of a protected procedure or entry call on the object since the
condition
was last evaluated.
An implementation may evaluate the
conditions
of all
entry_barriers
of a given protected object any time any entry of the object is checked
to see if it is open.
When an attempt is made to cancel an entry call,
the implementation need not make the attempt using the thread of control
of the task (or interrupt) that initiated the cancellation; in particular,
it may use the thread of control of the caller itself to attempt the
cancellation, even if this might allow the entry call to be selected
in the interim.
28 If an exception is raised during the
execution of an
entry_body,
it is propagated to the corresponding caller (see
11.4).
29 For a call on a protected entry, the
entry is checked to see if it is open prior to queuing the call, and
again thereafter if its Count attribute (see
9.9)
is referenced in some entry barrier.
30 In addition to simple entry calls, the
language permits timed, conditional, and asynchronous entry calls (see
9.7.2,
9.7.3,
and see
9.7.4).
31 The
condition
of an
entry_barrier
is allowed to be evaluated by an implementation more often than strictly
necessary, even if the evaluation might have side effects. On the other
hand, an implementation need not reevaluate the
condition
if nothing it references was updated by an intervening protected action
on the protected object, even if the
condition
references some global variable that might have been updated by an action
performed from outside of a protected action.
Examples
Examples of entry
calls:
Agent.Shut_Down; --
see 9.1
Parser.Next_Lexeme(E); --
see 9.1
Pool(5).Read(Next_Char); --
see 9.1
Controller.Request(Low)(Some_Item); --
see 9.1
Flags(3).Seize; --
see 9.4
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe