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

--- ai05s/ai05-0166-1.txt	2010/04/05 17:30:34	1.4
+++ ai05s/ai05-0166-1.txt	2010/04/20 23:33:33	1.5
@@ -1,6 +1,5 @@
-!standard  D.2.1(1.2/2)                            10-04-05    AI05-0166-1/04
+!standard  D.2.1(1.2/2)                            10-04-20    AI05-0166-1/05
 !standard  D.2.1(6/2)
-!standard  9.5.1(16)
 !standard  D.2.4(2/2)
 !standard  D.2.4(9/2)
 !class Amendment 09-10-22
@@ -80,15 +79,9 @@
 
 Add after D.2.1(6/2):
 
-A call of Yield is a task dispatching point (see D.2.1). It is a bounded error
-to call Yield from within a protected action.
+A call of Yield is a task dispatching point. Yield is a potentially blocking
+operation (see 9.5.1).
 
-
-Add after 9.5.1(14):
-
-  * a call to Ada.Dispatching.Yield (see D.2.1);
-
-
 Add after D.2.4(2/2):
 
 The following language-defined library package exists:
@@ -107,13 +100,19 @@
 higher priority task should never be on a ready queue while a lower priority
 task is executed. Thus, for such policies, Yield_To_Higher does nothing.
 
+Yield_To_Higher is *not* a potentially blocking operation; it can be used during
+a protected operation. That is allowed as any task with a higher priority than
+the protected operation cannot call the operation (that would violate the ceiling
+locking policy). An implementation-defined locking policy may need to define
+the semantics of Yield_To_Higher differently.
+End Ramification.
 
-Replace D.2.4(9/2):
 
-For this policy, a non-blocking delay_statement, a call to Yield_To_Higher and
-a call to Yield_To_Same_Or_Higher or Yield are the only non-blocking events
-that are task dispatching points (see D.2.1).
+Replace D.2.4(9/2):
 
+For this policy, a non-blocking delay_statement, a non-blocking call to 
+Yield_To_Higher, and a non-blocking call to Yield_To_Same_Or_Higher or Yield
+are the only non-blocking events that are task dispatching points (see D.2.1).
 
 !discussion
 
@@ -153,14 +152,7 @@
       ...
    end Iterator;
 
-!corrigendum 9.5.1(14)
 
-@dinsa
-@xbullet<task creation or activation;>
-@dinst
-@xbullet<a call to Ada.Dispatching.Yield (see D.2.1);>
-
-
 !corrigendum D.2.1(1.2/2)
 
 @drepl
@@ -185,17 +177,17 @@
 dispatching point it goes back to one or more ready queues; a task (possibly the
 same task) is then selected to run on that processor. The task selected is the one
 at the head of the highest priority nonempty ready queue; this task is then removed
-from all ready queues to which it belongs. 
+from all ready queues to which it belongs.
 @dinst
-A call of Yield is a task dispatching point. It is a bounded error
-to call Yield from within a protected action.
+A call of Yield is a task dispatching point. Yield is a potentially blocking operation 
+(see 9.5.1).
 
 
 !corrigendum D.2.4(2/2)
 
 @dinsa
 The @i<policy_>@fa<identifier> Non_Preemptive_FIFO_Within_Priorities is a task
-dispatching policy. 
+dispatching policy.
 @dinss
 The following language-defined library package exists:
 
@@ -215,9 +207,9 @@
 For this policy, a non-blocking @fa<delay_statement> is the only non-blocking event
 that is task dispatching point (see D.2.1).
 @dby
-For this policy, a non-blocking @fa<delay_statement>, a call to Yield_To_Higher
-and a call to Yield_To_Same_Or_Higher or Yield are the only non-blocking events
-that are task dispatching points (see D.2.1).
+For this policy, a non-blocking @fa<delay_statement>, a non-blocking call to 
+Yield_To_Higher, and a non-blocking call to Yield_To_Same_Or_Higher or Yield
+are the only non-blocking events that are task dispatching points (see D.2.1).
 
 
 !ACATS test
@@ -273,8 +265,8 @@
 as noted previously added after.)
 
 P.S. John would prefer to say that there should be a point after "point", which sounds
-like the department of redundancy dept. 
- 
+like the department of redundancy dept.
+
 ****************************************************************
 
 From: Randy Brukardt
@@ -300,5 +292,200 @@
 
 I'm sure I've forgotten what this is about, but the fact that that is possible is really
 bad.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, April 6, 2010  10:43 AM
+
+> Do we have to reopen the AI to do this, or just have the editor make
+> the needed changes??
+
+OK with me for the editor to do it.
+There's no change in intent here.
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, April 7, 2010  5:18 AM
+
+> P.S. John would prefer to say that there should be a point after
+> "point", which sounds like the department of redundancy dept.
+
+John would see no point in saying that there should be a point after "point".
+It should be a stop.
+
+But after a period such discussion seems pointless so we should stop.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Wednesday, April 14, 2010  4:15 AM
+
+> Apparently, we didn't look very carefully at this wording.
+
+This certainly seems to be true! There are a number of points in the three
+emails you sent Randy, all but one I agree with:
+
+> In AI05-0166-1 (which defines Yield and Yield_to_Higher), we added a
+> bullet to 9.5.1 (in the list of potentially blocking operations):
+>
+> * a call to Ada.Dispatching.Yield;
+>
+> But this is weird. First, it doesn't include
+> Ada.Dispatching.Non_Preemptive.Yield_to_Higher, which surely can be
+> blocking (for a non-preemptive policy, at least).
+>
+> Second, it is handled differently than all other language-defined
+> subprograms. 9.5.1(18) says that language-defined subprograms are not
+> potentially blocking unless they "are identified where they are
+> defined" (or are a file I/O routine, not relevant here). So, by
+> including Ada.Dispatching.Yield in this list and *not* identifying it
+> where defined, we have a contradiction.
+>
+> Compare how Yield is defined to how Suspend_Until_True is defined:
+> D.10(10) says specifically that it is a "potentially blocking operation".
+>
+> So I think those words need to be added after the other changes for
+> Yield and Yield_to_Higher: "Yield is a potentially blocking operation
+> (see 9.5.1)." and the same for Yield_to_Higher. And the bullet added
+> to 9.5.1 should be dropped.
+
+First for Yield - I agree that the fact that it is a potentially blocking
+operation should be stated where it is defined. And if that is done then there
+is no need to add to 9.5.1.
+
+But Yield_to_Higher is not, in the sense of 9.5.1, a potentially blocking
+operation. Yes it could lead to dispatching but it cannot cause any problems to
+a PO. If there is a task with a strictly higher active priority (and the system
+switches to that task) then this task will not call the PO (ceiling violation).
+So a call to Yield_to_Higher from within a PO is just the same (in a preemptive
+world) as switching to a higher priority task that become runnable while the PO
+is being executed.
+
+> I see another oddity. The definition of Yield in D.2.1:
+>
+>   "A call of Yield is a task dispatching point (see D.2.1). It is a
+> bounded error to call Yield from within a protected action."
+>
+> First, a cross-reference to the same clause is bogus. Second, saying
+> something is a bounded error without any definition of the bounds is
+> garbage. Besides, the definition of this as a potentially blocking
+> operation (however that is done, preferably the way the Ada 9X team
+> intended as outlined previously) has the right effect. So there should
+> be a period after "point" and the rest should be dropped. (With the
+> additional wording as noted previously added after.)
+
+Agree this should just say 'A call of Yield is a task dispatching point.'
+
+> The new wording for D.2.4(9/2) says:
+>
+> For this policy, a non-blocking @fa<delay_statement>, a call to
+> Yield_To_Higher and a call to Yield_To_Same_Or_Higher or Yield are the
+> only non-blocking events that are task dispatching points (see D.2.1).
+>
+> This doesn't make much sense, since a call to Yield, et. al. can be a
+> blocking operation (and clearly need to be "potentially blocking
+> operations"). Since it explicitly mentions "non-blocking" for a delay
+> statement, maybe it ought to mention "non-blocking" for the other two
+> as well.
+>
+> But really the entire statement is bogus. No one cares about "non-blocking"
+> anything, because by definition it didn't block. It's only interesting
+> if the task dispatching point changes the running task, and in that
+> case the task is blocked (stops running). So this isn't helpful, and
+> there is no AARM note to explain what it is talking about.
+
+
+Agree this should say:
+
+For this policy, a non-blocking @fa<delay_statement>, a call to Yield_To_Higher
+and a call to Yield_To_Same_Or_Higher or Yield are the only task dispatching
+points (see D.2.1).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 20, 2010  6:01 PM
+
+> This certainly seems to be true! There are a number of points in the 
+> three emails you sent Randy, all but one I agree with:
+
+Thanks for straightening out my confusion.
+ 
+...
+> > So I think those words need to be added after the other changes for 
+> > Yield and Yield_to_Higher: "Yield is a potentially blocking 
+> > operation (see 9.5.1)." and the same for Yield_to_Higher. And the 
+> > bullet added to 9.5.1 should be dropped.
+> >   
+> First for Yield - I agree that the fact that it is a potentially 
+> blocking operation should be stated where it is defined. And if that 
+> is done then there is no need to add to 9.5.1.
+> 
+> But Yield_to_Higher is not, in the sense of 9.5.1, a potentially 
+> blocking operation. Yes it could lead to dispatching but it cannot 
+> cause any problems to a PO. If there is a task with a strictly higher 
+> active priority (and the system switches to that task) then this task 
+> will not call the PO (ceiling violation). So a call to Yield_to_Higher 
+> from within a PO is just the same (in a preemptive
+> world) as switching to a higher priority task that become runnable 
+> while the PO is being executed.
+
+OK, I've added a Ramification that this is *not* a potentially blocking
+operation. I worry a bit whether this would be true for other locking policies
+than ceiling locking, but I suppose since those aren't defined by the language
+it's impossible to reason about them.
+
+...
+> > The new wording for D.2.4(9/2) says:
+> >
+> > For this policy, a non-blocking @fa<delay_statement>, a call to 
+> > Yield_To_Higher and a call to Yield_To_Same_Or_Higher or Yield are 
+> > the only non-blocking events that are task dispatching points (see D.2.1).
+> >
+> > This doesn't make much sense, since a call to Yield, et. al. can be 
+> > a blocking operation (and clearly need to be "potentially blocking 
+> > operations"). Since it explicitly mentions "non-blocking" for a 
+> > delay statement, maybe it ought to mention "non-blocking" for the 
+> > other two as well.
+> >
+> > But really the entire statement is bogus. No one cares about "non-blocking"
+> > anything, because by definition it didn't block. It's only 
+> > interesting if the task dispatching point changes the running task, 
+> > and in that case the task is blocked (stops running). So this isn't 
+> > helpful, and there is no AARM note to explain what it is talking about.
+> 
+> Agree this should say:
+> 
+> For this policy, a non-blocking @fa<delay_statement>, a call to 
+> Yield_To_Higher and a call to Yield_To_Same_Or_Higher or Yield are the 
+> only task dispatching points (see D.2.1).
+
+I don't think this works. I was confused about the meaning of "blocking" vs.
+"ready but not running". (The Janus/Ada runtime treats these as the same thing -
+a task is either running or blocked on some queue, but clearly the language does
+not.)
+
+D.2.1(4/2) says that anytime a task is blocked is a task dispatching point, and
+surely we mean that to be true for the non-premptive policy. Your proposed wording
+seems to say otherwise. I think we either need to stay closer to the original
+wording:
+
+   For this policy, a non-blocking @fa<delay_statement>, a non-blocking call to 
+   Yield_To_Higher, and a non-blocking call to Yield_To_Same_Or_Higher or Yield
+   are the only non-blocking events that are task dispatching points (see D.2.1).
+
+or simplify by listing everything:
+
+   For this policy, blocking or termination of a task, a @fa<delay_statement>,
+   a call to Yield_To_Higher and a call to Yield_To_Same_Or_Higher or 
+   Yield are the only task dispatching points (see D.2.1).
+
+   AARM Ramification: The last three items are task dispatching points even if non-blocking.
+
+The latter wording isn't quite as clearly talking about non-blocking cases,
+which seems to be the point of the paragraph, so I suspect that the first wording is
+better.
 
 ****************************************************************