Ada Conformity Assessment Authority      Home Conformity Assessment   Test Suite ARGAda Standard
Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

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. ]


{AI05-0030-2} requeue_statement ::= requeue procedure_or_entry_name [with abort];

Name Resolution Rules

{AI05-0030-2} {AI05-0215-1} 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

A requeue_statement shall be within a callable construct that is either an entry_body or an accept_statement, and this construct shall be the innermost enclosing body or callable construct.
{AI05-0030-2} {AI05-0215-1} If the requeue target has parameters, then its (prefixed) profile shall be subtype conformant with the profile of the innermost enclosing callable construct.
  {AI12-0090-1} 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. 
Discussion: Roughly speaking, the postcondition of the requeue target is required to imply that of the enclosing callable construct. 
  {AI12-0090-1} The requeue target shall not have an applicable specific or class-wide postcondition which includes an Old attribute_reference.
  {AI12-0090-1} 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.
Discussion: The above pair of rules always apply; they don't depend on whether or not any of the postconditions are enabled. 
  {AI05-0030-2} {AI05-0215-1} {AI12-0090-1} 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.
{AI05-0030-2} In a requeue_statement of an accept_statement of some task unit, either the target object shall be a part of a formal parameter of the accept_statement, or the accessibility level of the target object shall not be equal to or statically deeper than any enclosing accept_statement of the task unit. In a requeue_statement of an entry_body of some protected unit, either the target object shall be a part of a formal parameter of the entry_body, or the accessibility level of the target object shall not be statically deeper than that of the entry_declaration for the entry_body.
Ramification: In the entry_body case, the intent is that the target object can be global, or can be a component of the protected unit, but cannot be a local variable of the entry_body.
Reason: These restrictions ensure that the target object of the requeue outlives the completion and finalization of the enclosing callable construct. They also prevent requeuing from a nested accept_statement on a parameter of an outer accept_statement, which could create some strange "long-distance" connections between an entry caller and its server.
Note that in the strange case where a task_body is nested inside an accept_statement, it is permissible to requeue from an accept_statement of the inner task_body on parameters of the outer accept_statement. This is not a problem because all calls on the inner task have to complete before returning from the outer accept_statement, meaning no "dangling calls" will be created. 
Implementation Note: By disallowing certain requeues, we ensure that the normal terminate_alternative rules remain sensible, and that explicit clearing of the entry queues of a protected object during finalization is rarely necessary. In particular, such clearing of the entry queues is necessary only (ignoring premature Unchecked_Deallocation) for protected objects declared in a task_body (or created by an allocator for an access type declared in such a body) containing one or more requeue_statements. Protected objects declared in subprograms, or at the library level, will never need to have their entry queues explicitly cleared during finalization.

Dynamic Semantics

{AI05-0030-2} {AI12-0090-1} The execution of a requeue_statement proceeds by first evaluating the procedure_or_entry_name[, including the prefix identifying the target task or protected object and the expression identifying the entry within an entry family, if any]. Precondition checks are then performed as for a call to the requeue target entry or subprogram. 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);
Ramification: Note that for an internal requeue, the call is queued without checking whether the target entry is open. This is because the entry queues will be serviced before the current protected action completes anyway, and considering the requeued call immediately might allow it to "jump" ahead of existing callers on the same queue. 
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). 
 {AI05-0030-2} {AI05-0090-1} 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.
Ramification: This protection against cancellation lasts only until the call completes or a subsequent requeue-with-abort is performed on the call. 
Reason: We chose to protect a requeue, by default, against abort or cancellation. This seemed safer, since it is likely that extra steps need to be taken to allow for possible cancellation once the servicing of an entry call has begun. This also means that in the absence of with abort the usual Ada 83 behavior is preserved, namely that once an entry call is accepted, it cannot be cancelled until it completes. 
32  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 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

Extensions to Ada 83

The requeue_statement is new. 

Extensions to Ada 2005

{AI05-0030-2} {AI05-0215-1} Added the ability to requeue on operations of synchronized interfaces that are declared to be an entry. 

Inconsistencies With Ada 2012

{AI05-0090-1} Corrigendum: We now define that any preconditions of the requeue target are evaluated as part of a requeue_statement. Original Ada 2012 did not specify this, so a program that requeues when the preconditions fail will raise an exception when none would happen in original Ada 2012. We don't expect this to be a problem, as in that case, the entry body would be called with some of its preconditions evaluating as False; the body is likely to assume that they are true and probably will have failed in some other way anyway. 

Incompatibilities With Ada 2012

{AI05-0090-1} Corrigendum: If a requeue target has a different postcondition than the original entry, the requeue is now illegal. In such a case, the original postcondition would never have been evaluated, and assumptions that the caller relied upon might not be true. A requeue should be invisible to the caller with respect to any postconditions; thus we only allow it when the original entry has no postconditions or the requeue target has (at least) the same postconditions.

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe