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).
+
+***************************************************************
Questions? Ask the ACAA Technical Agent