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

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

--- ai12s/ai12-0267-1.txt	2018/12/02 08:13:18	1.10
+++ ai12s/ai12-0267-1.txt	2019/01/25 23:42:17	1.11
@@ -1,4 +1,4 @@
-!standard 9.5(57/5)                                     18-11-19  AI12-0267-1/07
+!standard 9.5(57/5)                                     19-01-25   AI12-0267-1/08
 !standard 9.10(11)
 !standard 9.10(15)
 !standard 9.10.1(0)
@@ -15,7 +15,7 @@
 !subject Data race and non-blocking checks for parallel constructs
 !summary
 
-Restrictions against potential data races and blocking are defined for
+Restrictions against potential data races and blocking for
 parallel constructs are defined. A policy-based mechanism is provided to
 control what level of restrictions are imposed for potential data races.
 
@@ -24,10 +24,10 @@
 Parallel execution can be a source of erroneous execution in the form of data
 races and deadlocking. As multicore computing becomes more prevalent, the
 concerns for improved safety with regard to parallel execution are expected to
-become more common-place. The proposals for the global and non-blocking aspects
+become more commonplace. The proposals for the global and non-blocking aspects
 should provide the compiler with semantic information to facilitate detection
 of these errors, but additional checking may be needed to determine if a
-parallelism construct is data-race free. The focus of this AI is to consider
+parallelism construct is free from data races. The focus of this AI is to consider
 any additional restrictions that may be needed to support these features.
 Similarly, if a compiler cannot determine if the parallelism is safe, then
 there ought to be a way for the programmer to explicitly override the
@@ -51,19 +51,19 @@
 Note that we distinguish "data race" from the more general term "race
 condition" where "data race" refers to the case where two concurrent
 activities attempt to access the same data object without appropriate
-synchronization, where at least one of the accesses updates the object.
+synchronization and at least one of the accesses updates the object.
 Such "conflicting" concurrent activities are considered erroneous in
 Ada, per section 9.10 of the reference manual. The more general term
 "race condition" includes other kinds of situations where the effect
 depends on the precise ordering of the actions of concurrent activities.
 Race conditions can be benign, or even intentional, and cannot easily be
 detected in many cases.  We make no particular attempt to prevent the
-more general notion of "race conditions," but we do hope to minimize
+more general notion of "race conditions", but we do hope to minimize
 data races.
 
 An important part of this model is that the compiler will complain if
-it is not able to verify that the parallel computations are independent
-(See AI12-0079-1 and AI12-0064-1 for ways on how this can happen).
+it is not able to verify that the parallel computations are independent.
+See AI12-0079-1 and AI12-0064-1 for how this can happen.
 
 Note that in this model the compiler will identify code where a
 potential data race (herein called a "potential conflict") occurs
@@ -71,14 +71,14 @@
 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
+consensus was that it would be better to define a range of compile-time
 levels of checking, and forego any use of run-time checks. Parallel
 constructs are only useful if they speed up a program, and complex
 run-time checks are almost certain to undermine any attempt at a speedup.
 
 This model also disallows potentially blocking operations within
 parallel block statements, parallel loop statements, and parallel reduce
-attributes, to simplify the implementation of these constructs, and to
+attributes. Doing so simplifies the implementation of these constructs, and to
 eliminate possibilities of deadlocking from occurring.
 
 We propose a Conflict_Check_Policy pragma to control the level of
@@ -118,7 +118,7 @@
   entry is defined to /potentially conflict/ with another action if the
   Global aspect (or Global'Class aspect in the case of a dispatching
   call) of the called subprogram or entry is such that a conflicting
-  action would be possible during the execution of the call. Similarly
+  action would be possible during the execution of the call. Similarly,
   two calls are considered to potentially conflict if they each have
   Global (or Global'Class in the case of a dispatching call) aspects
   such that conflicting actions would be possible during the execution
@@ -252,17 +252,17 @@
 standardize that capability until we know it is needed.  In general, to
 support blocking, a logical thread of control must get its own physical
 thread of control, which implies overhead that is not normally desired
-for relatively light-weight parallel constructs.
+for relatively lightweight parallel constructs.
 
-We have largely chosen to simply piggy-back on the existing rules in 9.5
+We have largely chosen to simply piggyback on the existing rules in 9.5
 about potentially blocking to disallow blocking in parallel constructs.
 To maximize safety, we are considering all parallel constructs to be
 implicitly "nonblocking" constructs, thereby moving the non-blocking
 check to compile time.
 
-As far as data-races, we have chosen to introduce the term "concurrent
-actions" in contrast to "sequential actions," to avoid the somewhat
-awkward term "non-sequential actions."  We have defined the terms
+As far as data races, we have chosen to introduce the term "concurrent
+actions" in contrast to "sequential actions", to avoid the somewhat
+awkward term "non-sequential actions".  We have defined the terms
 "conflicting" and "potentially conflicting" to simplify other wording
 that talks about data races. The distinction is that directly
 "conflicting" actions involve assignments and reads, while "potentially
@@ -273,19 +273,19 @@
 to concurrency associated with "normal" Ada tasking.
 
 We define four "conflict check policies" to control the level of checking
-that is performed to prevent data races.  The most restrictive policies
+that is performed to prevent data races. The most restrictive policies
 ensure that individual actions do not read or update variables that
-are visible to other logical threads of control.  This is quite
+are visible to other logical threads of control. This is quite
 conservative, as it will complain even if the given variable is
 manipulated by only one logical thread of control.
 
 The Known_Conflict_Checks policy is less restrictive, and is intended
-to only disallow conflicts that are clearly unsafe.  The Unchecked
+to only disallow conflicts that are clearly unsafe. The Unchecked
 policy imposes no restrictions whatsoever.
 
 It was felt that the default should be upward compatible with existing
-code, but completely safe for new uses of parallel constructs.  As such
-it disallows all uses of un-synchronized globals, unless the reference
+code, but completely safe for new uses of parallel constructs. As such
+it disallows all uses of unsynchronized globals, unless the reference
 is to an element of an array using either the loop parameter or
 the chunk index as the index into the array.
 
@@ -330,7 +330,7 @@
 entry is defined to @i<potentially conflict> with another action if the
 Global aspect (or Global'Class aspect in the case of a dispatching
 call) of the called subprogram or entry is such that a conflicting
-action would be possible during the execution of the call. Similarly
+action would be possible during the execution of the call. Similarly,
 two calls are considered to potentially conflict if they each have
 Global (or Global'Class in the case of a dispatching call) aspects
 such that conflicting actions would be possible during the execution

Questions? Ask the ACAA Technical Agent