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

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

--- ai12s/ai12-0119-1.txt	2018/06/30 01:06:51	1.20
+++ ai12s/ai12-0119-1.txt	2018/07/13 00:02:24	1.21
@@ -1,5 +1,8 @@
-!standard 5.5.2(2/3)                               18-06-23    AI12-0119-1/10
+!standard 2.9(2/3)                                   18-07-06    AI12-0119-1/11
+!standard 5.6.1(0)
 !class Amendment 14-06-20
+!status Amendment 1-2012 18-07-12
+!status ARG Approved 7-0-2  18-06-24
 !status work item 14-06-20
 !status received 14-06-17
 !priority Medium
@@ -19,18 +22,18 @@
 existing languages, safety concerns need to consider the paradigm shift from
 sequential to parallel behavior.
 
-Ada needs mechanisms to allow the programmer to specify explicity in the code
+Ada needs mechanisms to allow the programmer to specify explicitly in the code
 where parallelism should be applied. In particular, loops are often a good
-candidate for parallelisation, but there also needs to be a way to specify
-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
-perforamance concern, where it should be easy to convert an existing sequential
+candidate for parallelization, but there also needs to be a way to specify
+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 parallelization is mostly a
+performance 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
-rely more on the compiler to map the parallelism to the target platform.
+is too error prone, requires significant rework, more difficult to maintain, and
+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
 
@@ -57,7 +60,7 @@
 Add to the end of Introduction (28):
   Various parallel constructs, including parallel loops and parallel blocks,
   support the initiation of multiple logical threads of control designed
-  to execute in parallel when multipler processors are available.
+  to execute in parallel when multiple processors are available.
 
 Modify 2.9(2/3):
   Add "parallel" to the list of reserved words.
@@ -84,13 +87,14 @@
   same construct initiate such a transfer of control concurrently, one
   of them is chosen arbitrarily and the others are canceled.
 
-  When a logical thread of control is canceled, it causes it to complete
-  as though it had performed a transfer of control to the point where it
-  would have finished its execution.  Such a cancellation is deferred
-  while it is executing within an abort-deferred operation (see 9.8),
-  and may be deferred further, but not past a point where the logical
-  thread initiates a new nested parallel construct, or reaches an
-  exception handler.
+  When a logical thread of control is canceled, the cancellation causes
+  it to complete as though it had performed a transfer of control to the
+  point where it would have finished its execution. Such a cancellation
+  is deferred while the logical thread of control is executing within an
+  abort-deferred operation (see 9.8), and may be deferred further, but
+  not past a point where the logical thread initiates a new nested
+  parallel construct or reaches an exception handler that is outside
+  such an abort-deferred operation.
 
   Bounded (Run-Time) Errors
 
@@ -102,6 +106,11 @@
   blocking of some or all of the logical threads of control making up
   the current task.
 
+Modify 5.5(1):
+  [Redundant: A loop_statement includes a sequence_of_statements that is
+  to be executed repeatedly, zero or more times{ with the iterations
+  running sequentially or concurrently with one another}.]
+
 Replace 5.5(3/3):
 
 Iteration_scheme ::= while condition
@@ -136,15 +145,15 @@
   of a transfer of control). Prior to each such iteration, the
   corresponding value of the discrete subtype is assigned to the loop
   parameter. {If the reserved word parallel is present (a /parallel/
-  loop), each iteration is a separate logical thread of control (see 9),
-  with its own copy of the loop parameter; otherwise the} [These] values
-  are assigned {to the loop parameter} in increasing order unless the
-  reserved word reverse is present, in which case the values are
-  assigned in decreasing order.
+  loop), each iteration is a separate logical thread of control (see 
+  clause 9), with its own copy of the loop parameter; otherwise the} 
+  [These] values are assigned {to the loop parameter} in increasing 
+  order unless the reserved word reverse is present, in which case the
+  values are assigned in decreasing order.
 
 Add after 5.5(9/4):
 
-  AARM Implementation note: -- Each iteration of a parallel loop is a
+  AARM Implementation note: Each iteration of a parallel loop is a
   separate logical thread of control.  Normally these logical threads of
   control will be grouped into "chunks" for the purpose of execution to
   reduce the cost of creating large numbers of (physical) threads of
@@ -156,17 +165,17 @@
 
   -- See 3.6(30/2)
   parallel for I in Grid'Range(1) loop
-     Grid(I, 1) := (for all J in Grid'Rang(2)e => Grid(I,J) = True);
+     Grid(I, 1) := (for all J in Grid'Range(2) => Grid(I,J) = True);
   end loop;
 
 Add a new subclause:
 
 5.6.1 Parallel Block Statements
 
-A parallel_block_statement comprises two or more
+[Redundant: A parallel_block_statement comprises two or more
 handled_sequence_of_statements separated by *and* where each represents
 an independent activity that is intended to proceed concurrently with
-the others.
+the others.]
 
 Syntax
 
@@ -184,15 +193,15 @@
 Each handled_sequence_of_statements represents a separate logical thread
 of control that proceeds independently and concurrently. The
 parallel_block_statement is complete once every one of the
-handled_sequence_of_statements has completed, either by reaching the end of its
-execution, or due to a transfer of control out of the construct by one of the
-handled_sequence_of_statements (see 5.1).
-
-AARM Implementation Note -- Each handled_sequence_of_statements of a parallel
-block is a separate logical thread of control.  The implementation may
-choose to combine two or more such logical threads of control into a single
-physical thread of control to reduce the cost of creating numerous physical
-threads of control.
+handled_sequence_of_statements has completed, either by reaching the end
+of its execution, or due to a transfer of control out of the construct
+by one of the handled_sequence_of_statements (see 5.1).
+
+  AARM Implementation Note: Although each handled_sequence_of_statements
+  of a parallel block is a separate logical thread of control, the
+  implementation may choose to combine two or more such logical threads
+  of control into a single physical thread of control to reduce the cost
+  of creating numerous physical threads of control.
 
 Examples
 
@@ -270,6 +279,31 @@
      control} are performed by multiple physical processors acting in
      parallel, it may choose to perform them in this way.
 
+Add after 9.5.1(7/4):
+
+  If a parallel construct occurs within a protected action, no new
+  logical threads of control are created. Instead, each element of the
+  parallel construct that would have become a separate logical thread of
+  control executes on the logical thread of control that is performing
+  the protected action. If there are multiple such elements initiated
+  at the same point, they execute in an arbitrary order.
+
+  AARM Rationale: It would be feasible to allow multiple logical
+  threads of control within a protected action, but it would significantly
+  complicate the definition of "sequential" and "concurrent" actions,
+  since we generally presume that everthing occuring within protected
+  actions of a given protected object is sequential. We could simply
+  disallow any use of parallel constructs, but that seems unnecessary,
+  particularly as a parallel construct might be buried within a
+  subprogram that is declared Nonblocking.
+
+Add after 9.8(17):
+
+  * a point within a parallel construct where a new logical thread
+    of control is created;
+
+  * the end of a parallel construct;
+
 Modify 9.10(1/3):
 
   If two different objects, including nonoverlapping parts of the same
@@ -300,6 +334,25 @@
 
   Both actions occur as part of the execution of the same [task]
   {logical thread of control};
+
+Modify D.2.1(4/2) as follows:
+
+  Task dispatching is the process by which [one]{a logical thread of
+  control associated with a} ready task is selected for execution on a
+  processor. This selection is done [at certain points] during the
+  execution of [a task] {such a logical thread of control, at certain
+  points} called task dispatching points. [A task]{Such a logical
+  thread of control} reaches a task dispatching point whenever it
+  becomes blocked, and when [it] {its associated task} terminates. Other
+  task dispatching points are defined throughout this Annex for specific
+  policies. {Below we talk in terms of tasks, but in the context of a
+  parallel construct, a single task can be represented by multiple
+  logical threads of control, each of which can appear separately on a
+  ready queue.}
+
+Add at end of D.16.1(33/3):
+  The implementation may defer the effect of a Set_CPU or an Assign_Task
+  operation until the specified task exits an ongoing parallel construct.
 
 !discussion
 

Questions? Ask the ACAA Technical Agent