CVS difference for ai12s/ai12-0119-1.txt

--- ai12s/ai12-0119-1.txt	2018/09/05 21:28:45	1.23
+++ ai12s/ai12-0119-1.txt	2018/10/19 05:59:54	1.24
@@ -7908,3 +7908,142 @@
 Thoughts on this aside?
 
 ***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 6, 2018  6:41 AM
+
+> Having just finished added AI12-0119-1, I was checking AARM notes in 
+> 9.10 when I started wondering about all of the bullets 9.10(3-10). 
+> Specifically, the introductory text to this list of bullets in 9.10(2) 
+> was all changed from "task" to "logical thread of control".
+> 
+> Most of these bullets contain "task" in the wording. Upon closer 
+> inspection, most of them are about task-specific operations like 
+> activation, so no change is needed. However the first bullet seems like 
+> it might be a problem:
+> 
+>  * If A1 and A2 are part of the execution of the same task, and the 
+> language rules require A1 to be performed before A2;
+> 
+> It seems to me that we want this to apply to logical threads of 
+> control, and not just tasks. Otherwise, we would have no reason to 
+> treat two actions within the same logical thread of control to be 
+> sequential (as 9.10(13) claims is true). I was going to just change 
+> the text as an editorial review...but then I started wondering if we 
+> really need this rule about tasks as well.
+
+A given logical thread of control is always within a single task, so as 
+written, it subsumes a similar statement using "logical thread of control."
+In other words, if the language requires that A1 be performed before A2,
+then A1 signals A2.  Even saying that they are part of the same task is 
+probably redundant.  So long as the language establishes an order, it really
+doesn't matter whether they are part of the same logical thread of control,
+same task, same program, ...
+ 
+> Specifically, this rule as currently written says that an action that 
+> occurs inside of a parallel construct (possibly in different threads) 
+> is still sequential with actions that follow the parallel construct. 
+> If we only talked about logical threads of control, then we'd have no 
+> reason to make such an assumption (no signalling would happen).
+
+Yes, that is a good reason to leave it as is.
+
+> I'm at the limit of my knowledge here -- in particular, it's not clear 
+> to me why we needed both 9.10(3) and 9.10(13) in previous Ada. (If we 
+> didn't, then we don't need a new version of 9.10(3), either. But these 
+> rules were very carefully constructed, and unlike other parts of the 
+> language have hardly been touched in the intervening 23+ years.)
+
+9.10(3) talks about the language specifying an order.  9.10(13) says merely 
+that they are in the same logical thread of control, but no order is 
+specified by the language.  So they are quite different.  I believe they 
+work together properly, even with one talking about tasks and the other 
+talking about logical thread of control, because if two actions are part of
+the same logical thread of control, they are clearly part of the same task.
+
+> So, is there a problem here? Do we need to pull the AI to fix it (if a 
+> fix is required)?
+
+I don't believe so.
+
+> P.S. At a minimum, AARM notes 9.10(13.a) and (15.a) need to talk about 
+> "logical threads of control" rather than "tasks". I'm just making 
+> those corrections.
+
+Agreed
+ 
+> P.P.S. In a case of what Steve calls "heat vision", I noted an 
+> unrelated issue in this clause. Specifically, I suspect that 9.10(14) 
+> is wrong, because it doesn't take into account aspect 
+> Exclusive_Functions. If the action is of two protected functions with 
+> Exclusive_Functions set, the actions should be exclusive and thus 
+> should be sequential. (Since functions don't usually write anything, 
+> that usually isn't an issue -- but it could be an issue for something 
+> like the tampering indicator of a container -- which was the 
+> motivating case for aspect Exclusive_Functions.) The wording should 
+> talk about "exclusive protected operations" (which is what 9.5.1 uses 
+> these
+> days) rather than "protected functions", something like:
+> 
+> Both actions occur as part of protected actions on the same protected 
+> object, and at {least}[most] one of the actions is part of a call on 
+> {an exclusive protected operation}[a protected function] of the 
+> protected object.
+> 
+> Thoughts on this aside?
+
+Your suggested change makes sense to me.  Good catch!
+
+***************************************************************
+
+From: Randall Brukardt
+Sent: Thursday, September 6, 2018  5:18 PM
+
+...
+> > I'm at the limit of my knowledge here -- in particular, it's not 
+> > clear to me why we needed both 9.10(3) and 9.10(13) in previous Ada. 
+> > (If we didn't, then we don't need a new version of 9.10(3), either. 
+> > But these rules were very carefully constructed, and unlike other 
+> > parts of the language have hardly been touched in the intervening 
+> > 23+ years.)
+> 
+> 9.10(3) talks about the language specifying an order.  
+> 9.10(13) says merely that they are in the same logical thread of 
+> control, but no order is specified by the language.
+
+9.10(13) never says anything about an order, specified by the language or 
+otherwise. The AARM notes sort of imply that, but that seems irrelevant.
+
+> So they are quite different.
+
+Sure, but why did we need the first one (in the past)? Your response to this
+message implies that we did not (but do now, as discussed in the part that I
+left out of this reply).
+
+9.10(13) said that two actions in a single task (now LToC) are sequential 
+regardless of what the language says about their order. (In particular, they 
+are sequential if an order is specified as well as when it is unspecified.
+It's *always* the case.)
+
+So far as I can tell, "signalling" is not used in any rules other than this set
+of erroneous execution rules. So the rule about the language requiring an order
+is completely redundant with the rule for sequential actions. (Obviously, if
+"signalling" is used in some other rules, that wouldn't be true.)
+
+OTOH, in the current wording, actions are unconditionally sequential only when 
+they're in the same logical thread of control. The other wording says that it 
+also true if they're in different threads but the language requires an order
+(as in the parallel loop followed by a call situation, where actions taken by
+the loop have to occur before actions taken by the call). So now we need both.
+
+> I believe they work together
+> properly, even with one talking about tasks and the other talking 
+> about logical thread of control, because if two actions are part of 
+> the same logical thread of control, they are clearly part of the same 
+> task.
+
+Yes, I think I agree *now*. I still don't know why we needed that in the past
+ -- but it's moot in any case (there's no importance to determining an 
+answer).
+
+***************************************************************