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

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

--- ai05s/ai05-0030-1.txt	2007/05/05 01:39:15	1.3
+++ ai05s/ai05-0030-1.txt	2007/05/26 01:43:59	1.4
@@ -1,4 +1,4 @@
-!standard  9.5.4(3)                                       06-12-14    AI05-0030-1/00
+!standard  9.5.4(3)                                       07-05-15    AI05-0030-1/01
 !class Amendment 06-10-13
 !status work item 06-10-13
 !status received 06-10-13
@@ -12,25 +12,94 @@
 
 !problem
 
-** See Alan's mail **
+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
+OO and concurrency features of the language. 
 
 !proposal
 
-[Allow requeues on primitive procedures of synchronized interfaces. For a requeue
-on a real procedure (not an entry), raise Program_Error? Just call the procedure?
-Fall over dead? ;-)]
+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.
+
+There are three possible situations.
+
+1) The target is a function inside or outside a protected object -
+this is an error condition that can be caught at compile time;
+there are no circumstances whereby a function in an interface
+can be implemented by an entry. This is similar to the illegal case
+where a function call is used as the target of a timed/conditional
+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
+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
 
-(** TBD **)
+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).
 
 !discussion
 
-** TBD **
+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
 
-** Hopefully Alan will send one someday **
+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.
 
 !ACATS test
 
@@ -470,3 +539,122 @@
 it is too large for a Corrigendum change and if it is too incompatible.)
 
 ****************************************************************
+
+From: Alan Burns
+Sent: Monday, May 7, 2007  3:13 AM
+
+I'll await Pascal's advice, but I would rather have a discussion at the 
+ARG that decides on the 'best way forward', which I can then write up as
+an AI. If I  write one now the first minute of discussion will open up
+all the issues anyway. Also there are procedural as well as technical issues
+that I am not fully conversant with.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, May 7, 2007  3:46 AM
+
+I agree with Randy: we cannot discuss this topic in a vacuum, we need an
+AI on the table.  On the face of it what you propose in your paper seems
+to make sense, but in order to evaluate the impact on the language and on
+implementations, we need an AI with a fairly detailed description of what
+changes are needed where.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, May 7, 2007  7:36 AM
+
+OK, but our paper (and the subsequent discussion at IRTAW) did not really
+propose a complete solution, but it did strongly noted that:
+
+The workshop would wish to see Ada support requeue to a synchronized procedure
+implemented as an entry - but this leaves two big issues
+
+1) How to make this 'change' to Ada, ie can it be done now or must it wait
+   until 2015?
+2) What should happen if the synchronized procedure is not implemented 
+   as an entry; this is needed to complete the definition - there are three
+   possibilities
+  a) statically prevent via some language rule - or the use of a pragma
+  b) define it to be an error giving rise to an exception at run-time
+  c) allow and define what the semantics are.
+  The workshop's priority order was a), c) then b)
+
+The workshop also thought it desirable (though not essential) for timed 
+entry calls and ATCs to be dealt with in the same way as requeue.
+
+These two issues are linked (a solution now might be different from the solution
+for 2015), so I feel the ARG needs to decide what sort of solution (if any) it is 
+prepared to consider and how this would result in a language change. Perhaps
+some email discussion would help define what is possible - I could then write
+up the AI.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, May 7, 2007  9:39 AM
+
+> 1) How to make this 'change' to Ada, ie can it be done now or must it 
+> wait until 2015?
+
+It seems to me that we should at least consider making the change now.
+Otherwise there is no point in even discussing the issue until some time
+in 2014.  It may turn out that we collectively decide that the change
+would be too big or that the language is insufficiently broken, but I am
+in favor of at least having a discussion.  We must all keep in mind that
+we are in Corrigendum mode, though.
+
+> 2) What should happen if the synchronized procedure is not 
+> implemented 
+> as an entry;
+> this is needed to complete the definition - there are three 
+> possibilities
+> a) statically prevent via some language rule - or the use of a pragma
+> b) define it to be an error giving rise to an exception at run-time
+> c) allow and define what the semantics are.
+> The workshop's priority order was a), c) then b)
+
+My own feeling (which may not be shared by the rest of the ARG) is that
+(a) is either going to be too big (requiring new syntax and many new
+rules) or ugly (violating the rules of good taste for pragmas).  The three
+rules that you mention in section 4 of your paper appear to correspond to
+(c), and I'd say that we should at least give it a shot.  The alternative
+(b) looks very inconsistent with what we decided (for better or for worse)
+to do for timed entry calls and the like.
+
+So I suggest writing up the AI using approach (c).
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Monday, May 7, 2007  1:45 PM
+
+I agree.  As I see it, option (c) may take some work by implementors, 
+but it should be relatively minor, compared to the other options.  I 
+wrote about a page of detailed analysis, then deleted it as irrelevant.  
+I realized that any concern about difficultly can be reduced to one 
+case.  For the purpose of requeue, you may want to call a procedure of 
+another protected object.  If you can't use requeue, in that case, it 
+makes deadlock avoidance harder.  Sure you can modify the protected 
+object to have an entry similar to the current procedure, but have fun 
+trying to fix the semantics to get the same queuing behavior. So there 
+is a real, if accidental, hole here.
+
+What about requeuing on a procedure that really actually is a procedure, 
+and not part of a protected object?  I suspect that the right fix is to 
+change 9.5.4 (3) so that /entry/_name is defined as an entry name, a 
+procedure of a protected object, or a procedure from a task, protected 
+or interface type.  You should probably change /entry/_name as well, 
+here and in the paragraph above to /procedure_or_entry/_call and copy 
+the static semantics paragraph at 9.7.2(3.3/2).
+
+Oh, there is one other detail, but I hope not a big one.  What happens 
+if a requeue is made to a dispatching procedure of an interface type?  
+The actual type is not required to be an entry, or a subprogram of a 
+protected type.  What do compilers do now for other entry calls to such 
+procedures?  Should this be fixed in 3.9.4 and if so how?  Is this 
+another AI?  
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent