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

--- ai05s/ai05-0174-1.txt	2010/11/13 06:58:25	1.10
+++ ai05s/ai05-0174-1.txt	2011/02/12 08:36:48	1.11
@@ -1201,6 +1201,184 @@
 
 ****************************************************************
 
+From: Steve Baird
+Sent: Thursday, August 19, 2010  12:25 PM
+
+> Steve is responsible for this question in the first place; I would
+> hope that he has some opinion on how to fix it.
+
+Can we view
+
+    select
+        delay 1.0;
+        Foo;
+    then abort
+        Bar;
+    end select;
+
+as being equivalent to
+
+    declare
+        task T is
+           entry Done;
+        end;
+        task body T is
+        begin
+            Bar;
+            accept Done;
+        end T;
+    begin
+        select
+            T.Done;
+        or
+            delay 1.0;
+            abort T;
+            Foo;
+        end select;
+    end;
+
+and then define the interactions between ATC and Barriers in such a way as to
+maintain this equivalence?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 19, 2010  2:15 PM
+
+Indeed, during Ada 9X, the equivalence to aborting a task is what made some
+ATC-phobic folks tolerate having ATC in the language.  I think we added some
+restrictions to make the equivalence work (no accept statements inside ATC's?
+I'm too lazy to look it up.)
+
+> and then define the interactions between ATC and Barriers in such a
+> way as to maintain this equivalence?
+
+Sounds promising.  I've been too busy to follow this discussion, but Randy's
+getting frustrated, so maybe I'll get a round tuit.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 19, 2010  1:40 PM
+
+Sure, I thought that was what we discussed in Valencia. The problem was that the
+proposed wording doesn't make any sense, and since the AI was approved, I need
+the wording yesterday. (Seriously, I need it by Monday so I can finish the AARM
+draft.)
+
+With Tucker on vacation and you not answering, that isn't getting done. Please,
+someone suggest some *wording* that actually works and specifies something
+sensible for the ATC case.
+
+P.S. For the rest of you, we've been discussing this privately and not making
+any progress, thus the frustration. Everyone has been suggesting different
+rules, while I was only looking for a way to express the rule that we had
+already decided upon. Feel free to help out... Following is my original
+question:
+
+---
+
+In the minutes of the Valencia meeting, I have:
+
+Steve wonders what happens if one of these is used in ATC. He notes that it
+would be best if ATC and abort works the same way. The wording needs to be
+expanded to include ATC. Tucker suggests saying "When a call on Wait_for_Release
+is aborted..."
+
+The problem is that I can't reconcile Tucker's suggestion with the actual
+wording in the AI. The only wording in the AI that involves abort is:
+
+It is implementation-defined whether an abnormal task which is waiting on a
+Synchronous_Barrier object is aborted immediately or aborted when the tasks
+waiting on the object are released.
+
+Tucker's suggestion is very temporal: it occurs immediately; the existing
+wording simply says this is something that happens eventually at some point
+after the abort. Moreover, we can't talk about the task being aborted (because
+it isn't aborted for an ATC), so there is no noun. We can use "the call"
+instead, but then we have a tautology:
+
+When a call on Wait_for_Release is aborted, it is implementation-defined whether
+the call is aborted immediately or aborted when the tasks waiting on the object
+are released.
+
+This essentially says that when it is aborted, it is aborted now or later. But
+if it is aborted later, surely the prefix "when it is aborted" is not true,
+because it isn't aborted yet. Which makes the text senseless junk.
+
+Help!!
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, August 19, 2010  3:14 PM
+
+How about replacing
+
+   It is implementation-defined whether an abnormal task which is waiting
+   on a Synchronous_Barrier object is aborted immediately or aborted when
+   the tasks waiting on the object are released.
+
+with
+
+   It is implementation-defined whether the execution of a call to
+   Wait_For_Release includes the execution of any abort-deferred
+   operations. If the execution of a call to Wait_For_Release is in
+   progress when the execution of the enclosing sequence_of_statements
+   is aborted, then the call might or might not continue to completion
+   without being affected by the abort, the caller might or might
+   not be considered to be among the set of blocked tasks associated
+   with the Synchronous_Barrier object for purposes of determining
+   the cardinality of that set, and the calling task might or might
+   not be the selected task for which Released_Last is set to True
+   (even if the execution of that parameter copy-back is aborted).
+
+
+1) All we really need is the first sentence. I would argue that
+    everything in the second sentence is implied by the first.
+    Perhaps the second sentence should be an AARM note.
+
+2) Replace the use of "Released_Last" with whatever it was we
+    decided to change the name of that parameter to.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, August 19, 2010  3:33 PM
+
+Released_Last => Notified
+
+Otherwise looks good, but only the first sentence should be in the RM.
+For the AARM paragraph, a possible outcome should be that the program deadlocks,
+because the remaining tasks are never released?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 19, 2010  3:54 PM
+
+I agree that it looks good.
+
+And the deadlock possibility is why it doesn't make sense to use abort (in any
+form) with this construct, which is why we don't really care what happens.
+Probably should mention that in the AARM, not just the AI.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, August 19, 2010  3:59 PM
+
+> Otherwise looks good, but only the first sentence should be in the RM.
+> For the AARM paragraph, a possible outcome should be that the program
+> deadlocks, because the remaining tasks are never released?
+
+I think that is implicit in the "might or might not be considered to be among
+the set" wording. If it is not considered to be a member of the set of waiters,
+then of course the remaining waiters are not released until the set becomes big
+enough.
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Wednesday, October 20, 2010  6:22 PM
 
@@ -1319,8 +1497,8 @@
 No, I think I have it right. Specifically:
 
 --When a variable of type Synchronous_Barrier is created with Number_Waiting =
-N, --there are no waiting tasks and the barrier is set to block tasks. When the
-count --reaches N, all tasks are simultaneously released and the "Notified" out
+--N, there are no waiting tasks and the barrier is set to block tasks. When the
+--count reaches N, all tasks are simultaneously released and the "Notified" out
 --parameter is set to True in an arbitrary one of the callers. All other callers
 --result in "Notified" being set to False upon returning from the call.