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

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0427-1.txt

```--- ai12s/ai12-0427-1.txt	2021/06/03 02:16:53	1.5
+++ ai12s/ai12-0427-1.txt	2021/06/03 02:45:18	1.6
@@ -1724,3 +1724,88 @@
same entity}.

****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 31, 2021  11:14 AM
+
+Item (14) of this AI proposes the wording change to parallel blocks given
+below, to include an aspect_specification, as with all other parallel
+constructs.  I realized as I have been putting together a tutorial on the
+include a chunk count for a parallel block, as we have for essentially all
+other parallel constructs.  This is because a typical recursive divide and
+conquer parallel algorithm will want to use a parallel block, but will also
+want to control the number of logical threads spawned to handle the parallel
+block, as the nesting of recursion increases.  The easiest way to do this
+programmatically is to have the chunk count go to one once sufficient
+parallelism has been produced, or the problem has gotten sufficiently small.
+
+Note that in OpenMP there is always an ability to turn off further parallelism
+under similar circumstances, by having such a limit on the number of threads
+devoted to the construct.  As part of adding the aspect_specification to a
+parallel_block_statement, it makes sense to include a chunk_specification,
+but with the same restriction as is present for a parallel reduction, namely
+that the chunk_specificaiton is required to be an integer simple_expression
+(i.e. no named chunk parameter).
+
+Below I first give the wording change as initially proposed by AI12-0427-1,
+and then an alternative, which includes the chunk_specification.
+
+=====================
+
+Here is the proposal from AI12-0427-1:
+
+(14) Replace 5.6.1(2/5) with:
+
+parallel_block_statement ::=
+    parallel [aspect_specification] do
+       handled_sequence_of_statements
+    and
+       handled_sequence_of_statements
+   {and
+       handled_sequence_of_statements}
+    end do;
+
+Modify 5.6.1(3/5):
+
+   {For the execution of a parallel_block_statement, the aspect_specification,
+   if any, is elaborated. Then every}[Each] handled_sequence_of_statements{,
+   each of which} represents a separate logical thread of control{,
+   executes}[ 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).
+
+====
+
+And here is what I would now recommend:
+
+(14) Replace 5.6.1(2/5) with:
+
+  parallel_block_statement ::=
+    parallel [(chunk_specification)] [aspect_specification] do
+       handled_sequence_of_statements
+    and
+       handled_sequence_of_statements
+   {and
+       handled_sequence_of_statements}
+    end do;
+
+  The chunk_specification, if any, of a parallel_block_statement shall be an
+  /integer_/simple_expression.
+
+Modify 5.6.1(3/5):
+
+   {For the execution of a parallel_block_statement, the chunk_specification
+   and the aspect_specification, if any, are elaborated in an arbitrary order.
+   Then every}[Each] handled_sequence_of_statements{, each of which can}
+   represent[s] a separate logical thread of control{ (up to the maximum
+   specified by the value of the chunk_specification, if any), executes}[ that
+   proceeds] independently and concurrently{, again, up to the maximum if
+   specified}. 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).
+
+****************************************************************
```

Questions? Ask the ACAA Technical Agent