Go to the first, previous, next, last section, table of contents.
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 section 9.7 Select Statements.
entry_call_statement ::= entry_name [actual_parameter_part];
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 section 6.4 Subprogram Calls, and See section 6.4.1 Parameter Associations.
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 section 9.5 Intertask Communication.
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 task is open if the task is blocked on an accept_statement
that corresponds to the entry, See section 9.5.2 Entries and Accept Statements, or on a selective_accept,
See section 9.7.1 Selective Accept with an open accept_alternative that corresponds to the
entry; otherwise it is 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 section 6.4 Subprogram Calls.
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 section 9.5.1 Protected Subprograms and Protected Actions.
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 section 9.5.2 Entries and Accept Statements.
For a call on an open entry of a protected object, the corresponding
entry_body is executed, See section 9.5.2 Entries and Accept Statements, as part of the protected action.
If the accept_statement or entry_body completes other than by a requeue,
See section 9.5.4 Requeue Statements, 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 section 6.4.1 Parameter Associations, 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:
When the associated task reaches a corresponding accept_statement, or a
selective_accept with a corresponding open accept_alternative;
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 section D.4 Entry Queuing Policies.
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.
For an entry call that is added to a queue, and that is not the
triggering_statement of an asynchronous_select, See section 9.7.4 Asynchronous Transfer of Control, the
calling task is blocked until the call is cancelled, or the call is
selected and a corresponding accept_statement or entry_body completes
without requeuing. In addition, the calling task is blocked during a
An attempt can be made to cancel an entry call upon an abort,
See section 9.8 Abort of a Task - Abort of a Sequence of Statements, and as part of certain forms of select_statement,
See section 9.7.2 Timed Entry Calls, See section 9.7.3 Conditional Entry Calls, and See section 9.7.4 Asynchronous Transfer of Control. 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 section 9.5.4 Requeue Statements,
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
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 section 9.8 Abort of a Task - Abort of a Sequence of Statements. This applies equally to a simple
entry call and to an entry call as part of a select_statement.
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.
(26) If an exception is raised during the execution of an entry_body, it
is propagated to the corresponding caller, See section 11.4 Exception Handling.
(27) 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 section 9.9 Task and Entry Attributes, is referenced in some entry barrier.
(28) In addition to simple entry calls, the language permits timed,
conditional, and asynchronous entry calls, See section 9.7.2 Timed Entry Calls, See section 9.7.3 Conditional Entry Calls,
and See section 9.7.4 Asynchronous Transfer of Control.
(29) 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 of entry calls:
Agent.Shut_Down; -- See section 9.1 Task Units and Task Objects
Parser.Next_Lexeme(E); -- See section 9.1 Task Units and Task Objects
Pool(5).Read(Next_Char); -- See section 9.1 Task Units and Task Objects
Controller.Request(Low)(Some_Item); -- See section 9.1 Task Units and Task Objects
Flags(3).Seize; -- See section 9.4 Protected Units and Protected Objects
Go to the first, previous, next, last section, table of contents.