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

Differences between 1.16 and version 1.17
Log of other versions for file ai12s/ai12-0119-1.txt

--- ai12s/ai12-0119-1.txt	2018/03/30 07:55:07	1.16
+++ ai12s/ai12-0119-1.txt	2018/04/14 04:21:00	1.17
@@ -25,11 +25,11 @@
 parallelism more generally to allow potentially different groups of calls to
 be executed in parallel with other groups of calls. While Ada tasks can be used
 to generate parallel execution, they are better suited for separating concerns
-of independent processing where the need for parallelisation is mostly a 
+of independent processing where the need for parallelisation is mostly a
 perforamance concern, where it should be easy to convert an existing sequential
 algorithm into a parallel one, or vice versa. Declaring tasks for this purpose
 is too error prone, requires significant rework, more difficult to mainain, and
-not as easily transferable to different hardware platforms. It is better to 
+not as easily transferable to different hardware platforms. It is better to
 rely more on the compiler to map the parallelism to the target platform.
 
 !proposal
@@ -111,7 +111,7 @@
 of control before completing, the first occurrence of transfer of control is
 selected and the others are aborted.
 
-The parallel block completes when all of the parallel sequences complete, 
+The parallel block completes when all of the parallel sequences complete,
 either normally or by being aborted.
 
 Note that aborting a tasklet need not be preemptive, but should prevent
@@ -6653,15 +6653,15 @@
 Date: January 5, 2018 at 8:41:06 PM EST
 
 Hello Tucker,
- 
+
 My name is Fletcher McBeth.  I am working with the HPC group here at Intel
 Hudson and would very much enjoy receiving any and all updates you may be
 aware of towards getting your proposed constructs describing tasklets,
 parallel loops and parallel arrays/reductions thereof into the next version
 of Ada (hopefully 2020).
- 
+
 Thank you in advance.
- 
+
 ***************************************************************
 
 From: Brad Moore
@@ -6695,7 +6695,7 @@
 "requests."
 
 I would suggest you take a look at the introduction to chapter 9.  I suspect
-we will need to introduce the notion of "tasklet" somewhere.  I am thinking 
+we will need to introduce the notion of "tasklet" somewhere.  I am thinking
 that perhaps all of these things should be described somewhere in chapter 9,
 even if some of the syntax appears earlier.  If we don't coordinate the
 definition of parallel block and tasklet with the introduction to tasks in
@@ -6711,19 +6711,19 @@
 From: Randy Brukardt
 Sent: Thursday, March 29, 2018  6:15 PM
 
-I'm not sure I agree. He does define the tasklet semantics in chapter 9 (in 
+I'm not sure I agree. He does define the tasklet semantics in chapter 9 (in
 9.12, specifically). It probably wouldn't hurt to mention that in the
 introduction to chapter 9, too. [Oops, "Clause 9" if we're following current
 ISO-speak. :-)]
 
-OTOH, I don't think we want to hide the actual parallel blocks and loops in 
-Clause 9. Everyone "knows" that writing programs with tasks is hard, and 
-putting the parallel stuff there says that the same is true of them. Putting 
+OTOH, I don't think we want to hide the actual parallel blocks and loops in
+Clause 9. Everyone "knows" that writing programs with tasks is hard, and
+putting the parallel stuff there says that the same is true of them. Putting
 them with the basic statements signals that these are "easy" (there's nothing
-easier in Ada than Chapter 5!). Yes, that's marketing more than any major 
-semantic consideration -- but we all know that marketing and appearances 
-matter. That does require deferring some of the rules until the tasklet 
-subclause, and/or forward references. But it would seem very odd to have 
+easier in Ada than Chapter 5!). Yes, that's marketing more than any major
+semantic consideration -- but we all know that marketing and appearances
+matter. That does require deferring some of the rules until the tasklet
+subclause, and/or forward references. But it would seem very odd to have
 basic blocking and looping constructs away from the rest of those constructs.
 (And we hope/expect that parallel programming will get to be very basic during
 the lifetime of Ada 2020.)
@@ -6735,11 +6735,307 @@
 with checking that it is OK). Otherwise, they are just another control
 structure.
 
-So I think the current organization is approximately right (details to be 
+So I think the current organization is approximately right (details to be
 determined). This obviously is a "squishy" argument and this organization is
 not a big deal -- but we need to consider how this will look in 30 years. We
 don't want to hide basic control flow in an otherwise little-used clause
 (explicit tasks would be rare in a world where a lot of parallelism is applied
 automatically or by simple declarations).
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, April 3, 2018  6:19 AM
+
+We agreed to send these offline.
+
+!problem 2nd para
+“independent processing where” -> “independent processing, whereas” would
+seem better.
+
+Typos – “perforamance” -> “performance”, “mainain” -> “maintain”.
+
+Add after 5.5(7), 5.6.1 Static Semantics 2nd para
+
+It seems odd too talk of cancelling something that hasn’t yet started, maybe
+“inhibit” instead?
+
+5.6.1 Static Semantics
+
+It seems odd to describe transfer of control under Static Semantics rather
+than Dynamic Semantics – after all, the equivalent wording for parallel loops
+is under Dynamic Semantics.
+
+Modify 9.10(13)
+
+Typo – “part of a;” -> “part of a:”.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Monday, April 2, 2018  3:06 PM
+
+Here is an attempt to revise the introduction to "Tasks and Synchronization" to
+incorporate mention of "parallel constructs" without being more specific than
+talking about "multiple logical threads of control."
+
+Comments welcome.  The vocabulary of this introduction will probably form the
+basis for the descriptions of the semantics of parallel constructs, so it seems
+important to agree on it first.
+
+I purposely did not show the actual edits, so you can just read it to see if it
+makes sense.  The number of edits is actually relatively small.
+
+----------
+
+Modify section 9, Tasks and Synchronization:
+
+The execution of an Ada program consists of the execution of one or more tasks.
+Each task represents a separable activity that proceeds independently and
+concurrently between the points where it interacts with other tasks.  A single
+task, when in the context of a parallel construct, can represent multiple
+logical threads of control which can proceed in parallel.
+
+The various forms of task interaction are described in this clause, and include:
+
+1.a
+To be honest: The execution of an Ada program consists of the execution of one
+or more partitions (see 10.2), each of which in turn consists of the execution
+of an environment task and zero or more subtasks.
+
+2
+the activation and termination of a task;
+
+3
+a call on a protected subprogram of a protected object, providing exclusive
+read-write access, or concurrent read-only access to shared data;
+
+4
+a call on an entry, either of another task, allowing for synchronous
+communication with that task, or of a protected object, allowing for
+asynchronous communication with one or more other tasks using that same
+protected object;
+
+5
+a timed operation, including a simple delay statement, a timed entry call or
+accept, or a timed asynchronous select statement (see next item);
+
+6
+an asynchronous transfer of control as part of an asynchronous select statement,
+where a task stops what it is doing and begins execution at a different point in
+response to the completion of an entry call or the expiration of a delay;
+
+7
+an abort statement, allowing one task to cause the termination of another task.
+
+8
+In addition, tasks can communicate indirectly by reading and updating
+(unprotected) shared variables, presuming the access is properly synchronized
+through some other kind of task interaction.
+
+Static Semantics
+9
+The properties of a task are defined by a corresponding task declaration and
+task_body, which together define a program unit called a task unit.
+
+Dynamic Semantics
+10
+Over time, tasks proceed through various states. A task is initially inactive;
+upon activation, and prior to its termination it is either blocked (as part of
+some task interaction) or ready to run. While ready, a task competes for the
+available execution resources that it requires to run.  In the context of a
+parallel construct, a single task can utilize multiple processing resources
+simultaneously.
+
+10.a/3
+Discussion: {AI05-0229-1} The means for selecting which of the ready tasks to
+run, given the currently available execution resources, is determined by the
+task dispatching policy in effect, which is generally implementation defined,
+but may be controlled by aspects, pragmas, and operations defined in the
+Real-Time Annex (see D.2 and D.5).
+
+NOTES
+11
+1  Concurrent execution may be implemented on multicomputers, multiprocessors,
+   or with interleaved execution on a single physical processor. On the other
+   hand, whenever an implementation can determine that the required semantic
+   effects can be achieved when parts of the execution of a single logical
+   thread of control are performed by multiple physical processors acting in
+   parallel, it may choose to perform them in this way.
+
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, April 2, 2018  11:01 PM
+
+> I purposely did not show the actual edits, so you can just read it to
+> see if it makes sense.  The number of edits is actually relatively
+> small.
+
+As far as I can tell, you only added one sentence to the end of the first
+paragraph. I couldn't find anything else changed (but I didn't try a
+word-for-word comparison). Based on your earlier discussion, I was expecting
+more than that.
+
+> Modify section 9, Tasks and Synchronization:
+>
+> The execution of an Ada program consists of the execution of one or
+> more tasks. Each task represents a separable activity that proceeds
+> independently and concurrently between the points where it interacts
+> with other tasks.  A single task, when in the context of a parallel
+> construct, can represent multiple logical threads of control which can
+> proceed in parallel.
+
+This one new sentence is fine. But it seems strange that "threads of control"
+are never mentioned again. I realize that so long as we don't allow blocking in
+parallel constructs, there isn't much overlap -- but that makes me wonder why
+you were so concerned about rewriting this. Ergo, I have to think I'm missing
+something (or you are).
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 3, 2018  8:15 AM
+
+The changes were subtle, and it is interesting that you didn't notice them.  The
+first change was to describe a task as a "separable activity" rather than as a
+"logical thread of control."  Now that it can represent multiple threads of
+control, we needed a different way to describe a task -- hence, "separable
+activity."  Furthermore, the term "task" is omitted completely from the note
+about using multiple physical processors, and the term "logical thread of
+control" appears there as the thing that can be implemented using multiple
+physical processors.
+
+So the key shift here is that parallel constructs result in additional logical
+threads of control, and that a single task can represent multiple logical
+threads of control.
+
+...
+> As far as I can tell, you only added one sentence to the end of the
+> first paragraph. I couldn't find anything else changed (but I didn't
+> try a word-for-word comparison). Based on your earlier discussion, I
+> was expecting more than that.
+
+Here is one additional sentence, at the end of paragraph (10):
+
+"...  In the context of a parallel construct, a single task can utilize multiple
+processing resources simultaneously. "
+
+
+...
+> This one new sentence is fine. But it seems strange that "threads of
+> control" are never mentioned again.
+
+Threads of control are mentioned in the Note, and the term will presumably
+appear elsewhere when we talk about the dynamic semantics of parallel
+constructs.
+
+> I realize that so long as we don't allow blocking in parallel
+> constructs, there isn't much overlap -- but that makes me wonder why
+> you were so concerned about rewriting this. Ergo, I have to think I'm
+> missing something (or you are).
+
+There is a shift in vocabulary, which is subtle but important in my view.  A
+task is no longer considered a single logical thread of control.  Instead,
+parallel constructs can result in multiple logical threads of control in a
+single task, while a task is considered, as mentioned above, a "separable
+activity."
+
+***************************************************************
+
+From: Tullio Vardanega
+Sent: Tuesday, April 3, 2018  11:42 AM
+
+I can see the angle in the new opening paragraph, and the taxonomy that it
+implies. A task is a program entity that represents an activity whose execution
+can progress independently of (hence, separable from) its outside environment.
+That progress is realized by logical threads of control that can be assigned to
+physical processors. In the context of a parallel construct, a single separable
+activity may be assigned as many independent logical threads of control as the
+available physical processors.
+
+***************************************************************
+
+From: John Barnes
+Sent: Tuesday, April 3, 2018  11:58 AM
+
+Hmm.
+
+I haven't been following this in detail but I can see that (deo volente) I might
+have to rewrite my wretched book some day.
+
+I am not sure about
+
+In the context of a parallel construct, a single task can utilize multiple
+processing resources simultaneously.
+
+I could read this to mean that the task is inside some parallel construct rather
+than the other way around.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 3, 2018  12:10 PM
+
+How about:
+
+While the body of a task is executing a parallel construct, the task can utilize
+multiple processing resources simultaneously.
+
+***************************************************************
+
+From: John Barnes
+Sent: Tuesday, April 3, 2018  4:07 PM
+
+That would be crystal clear.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 3, 2018  6:13 PM
+
+> The changes were subtle, and it is interesting that you didn't notice
+> them.  The first change was to describe a task as a "separable
+> activity" rather than as a "logical thread of control."  Now that it
+> can represent multiple threads of control, we needed a different way
+> to describe a task -- hence, "separable activity."  Furthermore, the
+> term "task" is omitted completely from the note about using multiple
+> physical processors, and the term "logical thread of control"
+> appears there as the thing that can be implemented using multiple
+> physical processors.
+
+I see. So the big deal is to redefine tasks (I didn't pay much attention to them
+as they aren't changed, at least in how we think of them). I wouldn't have
+expected that is necessary, but it's clear if you want to do that, you need to
+do that immediately and not as some sort of bolt on.
+
+In any case, what you had read well and made sense. Indeed, I think it makes
+more sense even for tasks themselves than the original wording (which probably
+was overspecified) did.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 3, 2018  9:12 PM
+
+> That would be crystal clear.
+
+Probably should adjust the last sentence in paragraph (1) similarly:
+
+"... A single task, when in the context of a parallel construct, can represent
+multiple logical threads of control which can proceed in parallel."
+
+Might want to be instead:
+
+"... A single task, when executing a parallel construct, can represent multiple
+logical threads of control that can proceed in parallel."
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, April 4, 2018  2:11 PM
+
+Indeed - something like that.
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent