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

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0267-1.txt

--- ai12s/ai12-0267-1.txt	2018/10/19 05:59:55	1.8
+++ ai12s/ai12-0267-1.txt	2018/11/20 07:09:39	1.9
@@ -1,4 +1,4 @@
-!standard 5.1(1)                                      18-07-20  AI12-0267-1/06
+!standard 5.1(1)                                      18-11-19  AI12-0267-1/07
 !standard 9.5(57/5)
 !standard 9.10(11)
 !standard 9.10(15)
@@ -8,6 +8,8 @@
 !standard H.5(5/5)
 !standard H.5(6/2)
 !class Amendment 18-03-29
+!status Amendment 1-2012 18-11-19
+!status ARG Approved 5-0-2  18-10-21
 !status work item 18-03-29
 !status received 18-03-29
 !priority Medium
@@ -45,7 +47,8 @@
 This proposal depends on the facilities for aspect Global (AI12-0079-1) and
 for aspect Nonblocking (AI12-0064-2). Those proposals allow the compiler to
 statically determine where parallelism may be introduced without introducing
-data races or deadlocking.
+data races or deadlocking. We also depend, of course, on the definitions of
+parallel constructs and chunks from AI12-0119-1 and AI12-0251-1.
 
 Note that we distinguish "data race" from the more general term "race
 condition" where "data race" refers to the case where two concurrent
@@ -67,7 +70,7 @@
 Note that in this model the compiler will identify code where a
 potential data race (herein called a "potential conflict") occurs
 (following the rules for access to shared variables as specified in
-9.10, and point out where objects cannot be guaranteed to be
+9.10), and point out where objects cannot be guaranteed to be
 independently addressable. We considered using run-time checks to detect
 data overlap when compile-time checks were not feasible, but the
 consensus was that better would be to define a range of compile-time
@@ -142,6 +145,8 @@
 This subclause determines what checks are performed relating to possible
 concurrent conflicting actions (see 9.10).
 
+    Syntax
+
   The form of a Conflict_Check_Policy pragma is as follows:
 
     pragma Conflict_Check_Policy (/policy_/identifier);
@@ -155,8 +160,6 @@
   Parallel_Conflict_Checks, All_Conflict_Checks, or an implementation-defined
   conflict check policy.
 
-    Static Semantics
-
   A pragma Conflict_Check_Policy given in a declarative_part or
   immediately within a package_specification applies from the place of
   the pragma to the end of the innermost enclosing declarative region.
@@ -171,33 +174,32 @@
   construct, the conflict check policy is determined by the one in the
   innermost enclosing region. If no such Conflict_Check_Policy pragma exists,
   the policy is Parallel_Conflict_Checks (see below).
-
-      Implementation Requirements
 
-  The implementation shall impose restrictions related to possible
-  concurrent conflicting actions, according to which conflict check
-  policies apply at the place where the action or actions occur,
-  as follows:
+  Certain potentially conflicting actions are disallowed according to which
+  conflict check policies apply at the place where the action or actions 
+  occur, as follows:
 
   * Unchecked
     This policy imposes no restrictions.
 
   * Known_Conflict_Checks
-    If this policy applies to two concurrent actions, they are
+    If this policy applies to two concurrent actions occuring within the 
+    same compilation unit, they are
     disallowed if they are known to denote the same object (see 6.4.1)
     with uses that potentially conflict. For the purposes of this
     check, any parallel loop may be presumed to involve multiple
-    concurrent iterations, and any task type may be presumed to have
+    concurrent iterations, and any named task type may be presumed to have
     multiple instances.
 
   * Parallel_Conflict_Checks
-    This policy disallows a parallel construct from reading or updating
-    a variable that is global to the construct, unless it is a
-    synchronized object, or unless the construct is a parallel loop, and
-    the global variable is a part of a component of an array denoted by
-    an indexed component with at least one index expression that
-    statically denotes the loop parameter of the
-    loop_parameter_specification or the chunk index parameter of the
+    This policy includes the restrictions imposed by the
+    Known_Conflict_Checks policy, and in addition disallows a parallel 
+    construct from reading or updating a variable that is global to the 
+    construct, unless it is a synchronized object, or unless the construct 
+    is a parallel loop, and the global variable is a part of a component of
+    an array denoted by an indexed component with at least one index 
+    expression that statically denotes the loop parameter of the
+    loop_parameter_specification or the chunk parameter of the
     parallel loop.
 
   * All_Conflict_Checks
@@ -212,6 +214,10 @@
   implementation may disallow two concurrent actions if the
   implementation can prove they will at run-time denote the same object
   with uses that potentially conflict.
+
+  AARM Ramification: This permission allows additional enforcement in instance
+  bodies (where Legality Rules aren't usually enforced), in subunits and their
+  parents, and across compilation units, if the implementation wishes.
 
 Modify H.5(1/2):
   The following pragma [forces] {requires} an implementation to detect

Questions? Ask the ACAA Technical Agent