9.5.4 Requeue Statements
A
requeue_statement
can be used to complete an
accept_statement
or
entry_body,
while redirecting the corresponding entry call to a new (or the same)
entry queue.
Such a
requeue can be performed
with or without allowing an intermediate cancellation of the call, due
to an abort or the expiration of a delay.
Syntax
requeue_statement ::= requeue procedure_or_entry_name [
with abort];
Name Resolution Rules
The
procedure_or_entry_name
of a
requeue_statement
shall resolve to denote a procedure or an entry (the
requeue target).
The profile of the entry, or the profile or prefixed profile of the procedure,
shall either have no parameters, or be type conformant (see
6.3.1)
with the profile of the innermost enclosing
entry_body
or
accept_statement.
Legality Rules
If the requeue target has parameters, then its (prefixed)
profile shall be subtype conformant with the profile of the innermost
enclosing callable construct.
Given a requeue_statement
where the innermost enclosing callable construct is for an entry E1,
for every specific or class-wide postcondition expression P1 that
applies to E1, there shall exist a postcondition expression P2
that applies to the requeue target E2 such that
P1 is fully conformant with the expression
produced by replacing each reference in P2 to a formal parameter
of E2 with a reference to the corresponding formal paramter of
E1; and
if P1 is enabled, then P2 is also
enabled.
The requeue target shall not have an applicable
specific or class-wide postcondition that includes an Old or Index
attribute_reference.
If the requeue target is declared immediately within
the
task_definition
of a named task type or the
protected_definition
of a named protected type, and if the requeue statement occurs within
the body of that type, and if the requeue is an external requeue, then
the requeue target shall not have a specific or class-wide postcondition
which includes a name denoting either the current instance of that type
or any entity declared within the declaration of that type.
If the target is a procedure, the name shall denote
a renaming of an entry, or shall denote a view or a prefixed view of
a primitive subprogram of a synchronized interface, where the first parameter
of the unprefixed view of the primitive subprogram shall be a controlling
parameter, and the Synchronization aspect shall be specified with
synchronization_kind
By_Entry for the primitive subprogram.
Dynamic Semantics
1.
The
procedure_or_entry_name
is evaluated. This includes evaluation of the
prefix
(if any) identifying the target task or protected object and of the
expression
(if any) identifying the entry within an entry family.
2.
If the target object is not a part of a formal parameter of the innermost
enclosing callable construct, a check is made that the accessibility
level of the target object is not equal to or deeper than the level of
the innermost enclosing callable construct. If this check fails, Program_Error
is raised.
3.
Precondition checks are performed as for a call to the requeue target.
4.
The
entry_body
or
accept_statement
enclosing the
requeue_statement
is then completed, finalized, and left (see
7.6.1).
For the execution of a requeue
on an entry of a target task, after leaving the enclosing callable construct,
the named entry is checked to see if it is open and the requeued call
is either selected immediately or queued, as for a normal entry call
(see
9.5.3).
For
the execution of a requeue on an entry of a target protected object,
after leaving the enclosing callable construct:
if the requeue is an internal requeue (that is,
the requeue is back on an entry of the same protected object —
see
9.5), the call is added to the queue of
the named entry and the ongoing protected action continues (see
9.5.1);
if the requeue is an external requeue (that is,
the target protected object is not implicitly the same as the current
object — see
9.5), a protected action
is started on the target object and proceeds as for a normal entry call
(see
9.5.3).
If the requeue target named in the
requeue_statement
has formal parameters, then during the execution of the
accept_statement
or
entry_body
corresponding to the new entry and during the checking of any preconditions
of the new entry, the formal parameters denote the same objects as did
the corresponding formal parameters of the callable construct completed
by the requeue. In any case, no parameters are specified in a
requeue_statement;
any parameter passing is implicit.
If
the
requeue_statement
includes the reserved words
with abort (it is a
requeue-with-abort),
then:
if the original entry call has been aborted (see
9.8), then the requeue acts as an abort completion
point for the call, and the call is cancelled and no requeue is performed;
if the original entry call was timed (or conditional),
then the original expiration time is the expiration time for the requeued
call.
If the reserved words
with abort do not appear,
then the call remains protected against cancellation while queued as
the result of the
requeue_statement.
NOTE A requeue is permitted from
a single entry to an entry of an entry family, or vice versa. The entry
index, if any, plays no part in the subtype conformance check between
the profiles of the two entries; an entry index is part of the
entry_name
for an entry of a family.
Examples
Examples of requeue
statements:
requeue Request(Medium)
with abort;
--
requeue on a member of an entry family of the current task, see 9.1
requeue Flags(I).Seize;
--
requeue on an entry of an array component, see 9.4
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
