CVS difference for ai05s/ai05-0030-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0030-1.txt

--- ai05s/ai05-0030-1.txt	2007/05/26 01:43:59	1.4
+++ ai05s/ai05-0030-1.txt	2007/10/09 19:35:43	1.5
@@ -1,28 +1,102 @@
-!standard  9.5.4(3)                                       07-05-15    AI05-0030-1/01
+!standard  9.5.4(3)                                   07-09-27    AI05-0030-1/02
 !class Amendment 06-10-13
 !status work item 06-10-13
 !status received 06-10-13
 !priority Medium
 !difficulty medium
-!subject Requeue on sychronized interfaces
+!subject Requeue on synchronized interfaces
 
 !summary
 
-(See proposal.)
+Requeue is permitted to a synchronized, task, or protected interface. It
+is a bounded error if the actual target procedure is not implemented as
+an entry.
 
 !problem
 
 The inability to requeue to a synchronized, task or protected interface
 is a serious drawback when trying to produce general-purpose real-time
-utilities. Its inclusion would furthers the integration of the
+utilities. Its inclusion would further the integration of the
 OO and concurrency features of the language. 
 
 !proposal
 
 The proposal is to allow requeue to procedures defined in synchronized,
-task or protected interfaces. The key aspect of this proposal is the semantics
-for the situation where the target procedure is not implemented as an entry.
+task, or protected interfaces. If it turns out that the target procedure
+is not implemented as an entry then it is a bounded error. Possible
+consequences of the bounded error are
 
+*  Program_Error is raised at the point of the requeue, or
+
+*  if the procedure is implemented as a protected procedure, then
+   it behaves as if the procedure were an entry with a True barrier, or
+
+*  if the procedure is implemented as a normal procedure, then after
+   leaving the enclosing callable context, the procedure is executed.
+
+
+!wording
+
+Change 9.5.4(2-5) to
+
+   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 target procedure or entry). In the
+case of an entry, the entry shall have a profile that has no parameters,
+or that is type conformant (see 6.3.1) with the profile of the innermost
+enclosing entry_body or accept_statement. In the case of a procedure,
+the name shall denote a rename of an entry whose profile satisfies the
+above requirement, or shall denote a prefixed view of a primitive 
+subprogram of a synchronized interface where the profile of the prefixed 
+view satisfies the above requirement, and the first parameter of the 
+unprefixed view of the primitive subprogram shall be a controlling 
+parameter.
+
+           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.
+
+If the target procedure (view) or entry has parameters, then its 
+profile shall be subtype conformant with the profile of the innermost 
+enclosing callable construct.
+
+Modify 9.5.4(7) as follows
+
+The execution of a requeue_statement proceeds by first evaluating the
+[*entry_*name]{*procedure_or_entry_*name} ...
+
+Modify 9.5.4(12) as follows
+
+If the new {procedure or }entry named in the requeue_statement has 
+parameters, then during the execution of [the]{an} accept_statement 
+or entry_body corresponding to [the]{a} new entry ...
+
+Add after 9.5.4(16)
+
+                Bounded (Run-Time) Errors
+
+It is a bounded error to requeue to an interface procedure not 
+implemented as an entry. Program_Error is raised at the point of the
+requeue if the error is detected by the implementation; otherwise, if 
+the procedure is implemented by a protected procedure then the requeue 
+statement behaves as if the procedure were an entry whose barrier is 
+True, and if the procedure is not a protected procedure then, after 
+leaving the enclosing callable context, the procedure is executed. In 
+both cases of implementation by a procedure, the formal parameters 
+denote the same objects as the corresponding formal parameters of the 
+original call.
+
+
+!discussion
+
+The key problem to be resolved is what should happen if the target turns 
+out to be implemented as a subprogram and not as an entry.
+
 There are three possible situations.
 
 1) The target is a function inside or outside a protected object -
@@ -33,73 +107,65 @@
 entry call or as a triggering event in a select-then-abort statement.
 
 2) The target is a procedure inside a protected object - this is similar
-to the case where the target of a timed/condition entry call or
+to the case where the target of a timed/conditional entry call or
 select-then-abort triggering event turns out to be a procedure that has
 been implemented inside of a protected type implementing the associated
-interface. The corresponding interpretation would be to view the procedure
-as an entry with a ``when True" barrier. 
-
-3) The target is a regular procedure (i.e. outside a protected object/task) -
-this is similar to the case where the target of a timed/condition entry call
-or select-then-abort triggering event turns out to be a procedure outside of
-the protected object/tasks implementing the associated interface. As this would
-succeed in this case, so should it succeed in the requeue case.
-However, to execute the procedure immediately would mean that the procedure would
-be executed at the ceiling priority of the original protected type (or the priority
-of the original rendezvous). This would seem to be wrong. Hence, the calling
-task/protected objects accept statement/entry code's body is ``completed,
-finalised and left" (ARM, Section 9.5.4) and then the procedure is called
-with the priority of the original thread.
-
-The difference between 2) and 3) is the observed order of execution in certain
-circumstances. Consider a protected object PO from which a requeue occurs; the PO
-also has a blocked entry that is now open (as the task leaves the PO) - this
-will allow the entry E1 to execute. If the requeue is to another protected entry,
-E2, that is open (or to a protected procedure) then E2 will execute before
-E1 as the target protected object has a higher or equal priority. However if
-the target is an ordinary procedure, P, then E1 will execute before P.
-
-To cater for this circumstance the run-time must deal with ordinary procedures
-in a different way - they cannot be executed by another thread on behalf the
-caller, the genuine caller thread (without an inherited priority) must execute
-the procedure.
-
-Alternative approach
-As an alternative to the proposal given above, it could be argued that attempting to
-requeue to a non-entry is an error condition and a run-time exception should be raised.
-
-Of course, where the programmer knows that the intended target is an entry, 
-ideally there should be a mechanism to indicate this (perhaps by a pragma).
-This would allow the compiler to check, thereby avoiding the run-time error.
-
-!wording
-
-9.5.4(3) and 9.5.47) must be modified to allow a procedure that is a primitive
-operation of a limited interface; the changes must be similar to those
-made in 9.7.2(3.2/2).
-
-In the dynamic semantics there are existing paragraphs - 9.5.4(8-11) - that
-deal with the target of a requeue being either an entry of task or an entry
-in a protected object. Two further paragraphs would need to be added to
-cater for the target being a protected procedure, or a regular procedure
-(that has been derived from a synchronised interface).
+interface. The corresponding interpretation might be to view the procedure
+as an entry with a True barrier. 
 
-!discussion
+3) The target is a regular procedure (i.e. outside a protected 
+object/task) -this is similar to the case where the target of a 
+timed/conditional entry call or select-then-abort triggering event 
+turns out to be a procedure outside of the protected object/tasks 
+implementing the associated interface. As this would succeed in this 
+case, so should it succeed in the requeue case. However, to execute 
+the procedure immediately would mean that the procedure would
+be executed at the ceiling priority of the original protected type 
+(or the priority of the original rendezvous). This would seem to be 
+wrong. Hence, the accept statement or entry code body of the calling 
+task or protected object should be "completed, finalized and left" 
+(ARM, Section 9.5.4) and then the procedure called with the priority 
+of the original thread.
+
+The difference between 2) and 3) is the observed order of execution 
+in certain circumstances. Consider a protected object PO from which a
+requeue occurs; the PO also has a blocked entry that is now open 
+(as the task leaves the PO) - this will allow the entry E1 to execute. 
+If the requeue were to another protected entry, E2, that is open (or to a 
+protected procedure) then E2 would execute before E1 as the target 
+protected object has a higher or equal priority. However if the target 
+were an ordinary procedure, P, then E1 would execute before P.
+
+To cater for this circumstance the run-time would have to deal with 
+ordinary procedures in a different way - they could not be executed by
+another thread on behalf of the caller - the genuine caller thread 
+(without an inherited priority) should execute the procedure.
+
+However, it was concluded that it would be too much of an 
+implementation burden to insist on this and accordingly it was 
+decided that it is a bounded error to requeue to a non-entry.
+
+Of course, where the programmer knows that the intended target is 
+an entry, ideally there should be a mechanism to indicate this 
+(perhaps by a pragma). This would allow the compiler to check, 
+thereby avoiding the bounded error. Such a possibility has been 
+left for possible further consideration in another AI in the 
+future. (Javier Miranda has indicated that he is prepared
+to develop a prototype implementation to evaluate the impact of 
+such a proposal.)
+
+When discussed at the IRTAW the need to requeue via interface 
+procedures implemented by entries was strongly supported. However 
+there was no wish to have requeue to a procedure so the proposal 
+of this present AI covers the perceived need.
 
-It is not currently clear how much effort, in terms of changes to the run-time
-will be needed by this proposal. Javier Miranda has indicated that he is prepared
-to develop a prototype implementation to evaluate the impact of the proposal.
-
-When discussed at the IRTAW the need to requeue via interface procedures implemented
-by entries was strongly supported. However there was no wish to have 'requeue to
-a procedure', so the semantics above is all to do with completing the definition
-rather than adding useful functionality.
-
 !example
 
 See the paper 'Integrating OOP and Tasking - the missing requeue' by
 Wellings and Burns (IRTAW2007), previously circulated. Find it at
 http://www.ada-auth.org/ai-files/grab_bag/requeue.pdf.
+
+!corrigendum
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent