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

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

--- ai12s/ai12-0092-1.txt	2015/02/21 04:29:26	1.11
+++ ai12s/ai12-0092-1.txt	2018/03/02 06:46:44	1.12
@@ -8711,3 +8711,109 @@
 enable these warnings, make them errors, or suppress them completely.
 
 ***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 20, 2018  4:11 PM
+
+> ...
+> I thought that the intent was that the parallelism checking would be a 
+> "suppressible error", such that one could disable it with a pragma. 
+> (That of course assumes that we define the concept.)
+
+Rather than making this depend on the "suppressible error" concept which 
+remains controversial and incompletely defined, I suggest we simply define a
+Restriction identifier such as "No_Data_Races", perhaps in Annex H, and give
+the rules there.  Restrictions are already a part of the language, and already
+support granularity at the compilation-unit level as well as at the
+library-wide level.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 20, 2018  6:10 PM
+
+Other than that the sense is backwards (you'd really want these checks to be
+the default, having to do something to turn them off) this seems like an
+appealing idea. I'd be a bit worried about the granularity of entire
+compilation units (usually, I would think you'd want to not have a check on a
+specific subprogram but still have checks on the rest), but we can worry about
+that later.
+
+Aside: We just finally got rid of one rule where the sense is backwards, with
+pragma Detect_Blocking (which should have been the default) now being subsumed
+by aspect Nonblocking. Somewhat annoying to introduce another one.
+End aside.
+
+And the name of the restriction would be a bit of issue. "No_Data_Races" is 
+promising quite a bit! It's probably more like "No_Obvious_Data_Races". :-)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 20, 2018  8:55 PM
+
+Having thought about this more, I think this is the right approach, but
+because the sense is backwards, we need a slightly different formulation.
+So, in the interests of trying to get this correct, let me throw the following
+idea at the wall:
+
+---
+
+Define pragma Allow, which has a list of allowances. This works very much like
+a pragma Restriction, except that "Allow" turns *off* checks that are
+otherwise on. I think these would always be per-unit allowances (but we can 
+discuss that). (One could think of this as a Restriction that is always on
+unless in the scope of pragma Allow.) Here's some sample wording:
+
+   The form of a pragma Allow is as follows: 
+
+       pragma Allow(allowance{, allowance});
+
+       allowance ::= allowance_identifier
+
+[The rules for evaluating restrictions as given in 13.12(8-8.6) are
+appropriately modified and included here.]
+
+The following Allowances are language-defined: [Note: Recall that the word
+"allow" precedes these syntactically.]
+
+Data_Races_in_Parallel_Constructs
+    Checks that prevent data races in parallel constructs (parallel blocks, 
+    parallel loops, attribute Parallel_Reduce) are not made. Specifically, the
+    requirements on the use of global objects are not enforced, and the
+    runtime checks on global array objects are not performed.
+
+Blocking_in_Parallel_Constructs
+    Checks that prevent blocking in parallel constructs (parallel blocks,
+    parallel loops, attribute Parallel_Reduce) are not made. Specifically, the
+    requirement that calls are only made to subprograms with aspect
+    Nonblocking being True are not enforced. If a parallel construct executes
+    a potentially blocking operation, execution is erroneous. [The last
+    statement probably ought to go into the parallel construct definitions.]
+
+Race_Conditions_in_Synchronized_Access
+    Checks that reduce race conditions in any subprogram that is defined (via 
+    aspect Global) to support synchronized access are not made. In particular,
+    this allows unlimited usage of atomic objects in such subprograms.
+
+---
+
+The basic idea is to define these things much like a restriction, but to
+invert the sense so that it is eliminating checks that aren't always needed.
+All of these would be helpful to users with existing code (without all of the
+needed contract information) that they are sure is task-safe). If they are
+wrong, of course, execution will be erroneous and probably will produce
+garbage, but these "allowances" would let people use the parallel mechanism
+on a trust basis if they wish. But the default would be for safe (or at least,
+as safe as we can reasonably make it) -- one would have to explicitly put
+something in their code for code reviewers to see that says that the safety
+checks are turned off.
+
+I structured this so that common readers of the RM would see the safety checks
+by default. But we could also structure them even more like restrictions (just
+restrictions that are on by default), putting the actual definitions of the
+checks here with the allowances.
+
+Praise and brickbats welcome (one more than the other :-).
+
+***************************************************************

Questions? Ask the ACAA Technical Agent