Version 1.1 of ai12s/ai12-0267-1.txt
!standard 5.5(6/5) 18-03-29 AI12-0267-1/01
!class Amendment 18-03-29
!status work item 18-03-29
!status received 18-03-29
!subject Data race and non-blocking checks for explicit parallelism
Data race and non-blocking checks for explicit parallelism are defined.
Mechanisms to enable and disable these checks are provided.
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
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
any additional checks that may be needed to support these features. Similarly,
if a compiler cannot determine if the parallelismn is safe, then there ought to
be a way for the programmer to explicitly override the conservative approach of
the compiler and insist that parallelism should be applied, even if data races
or deadlocking problems can potentially occur.
Ada needs mechanisms whereby the compiler is given the necessary semantic
information to enable the implicit and explicit parallelization of code.
After all, the current Ada language only allows parallel execution when
it is semantically neutral (see 1.1.4(18) and 11.6(3/3)) or explicitly
in the code as a task.
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.
An important part of this model is that if the compiler is not able to
verify that the parallel computations are independent, then a warning
will be issued at compile time (See AI12-0079-1 and AI12-0064-1 for
ways on how this can happen).
Note that in this model the compiler will identify any code where a
potential data race occurs (following the rules for concurrent access
to objects as specified in the 9.10(11-14), and point out where objects
cannot be guaranteed to be independently addressable. If not determinable
at compile-time, the compiler may insert run-time checks to detect data
This model also disallows potentially blocking operations within parallel
block statements, parallel loop statements, and parallel reduce attributes,
to simplify the implementation of tasklets, and to eliminate possibilities of
deadlocking from occurring.
Add after 5.5(6/5)
A loop_statement with the parallel reserve word shall not update variables
global to the loop unless either the action is sequential (see 9.10), or the
expression for the update mentions the loop parameter.
The sequence_of_statements of a loop_statement with the parallel reserved word
shall not consist of a statement that can invoke a potentially blocking
operation (see 9.5).
Add after 5.5(9/4)
For a parallel loop, a check is made that updates to a component of a global
array or to an element of a container via an expression that mentions the loop
parameter is sequential. See 9.10.
The check ensures that different tasklets executing iterations of the same loop
in parallel will not involve data races. These checks are not needed if it can
statically be determined that each iteration of the loop accesses a unique set
of array components or container elements via the loop parameter.
5.6.1 Parallel Block Statements
A parallel_block_statement shall not update variables global to the loop unless
the action is sequential (see 9.10).
A handled_sequence_of_statements of a parallel_block_statement shall not consist
of a statement that can invoke a potentially blocking operation (see 9.5).
Add after 11.5(20)
For a parallel loop, check that updates to a component of an array or to an
element of a container via the loop parameter are sequential. See 9.10.
It is important for the programmer to receive an indication from the compiler
whether the desired parallelism is safe, or even worthwhile.
We considered whether blocking calls should be allowed in a parallel block
statement. We felt that allowing that could add significant complexity for
the implementor, as well as introduce safety concerns about potential deadlocking.
While such a capability is possible, it was felt that it should be disallowed
for now. If the demand and need is felt in the future, it could be added then,
but it is better to not standardize that capability until we know it is needed.
ACATS B- and C-Tests are needed to check that the new capabilities are
From: Brad Moore
Sent: Wednesday, March 28, 2018 12:12 AM
This is a new AI extracted from AI12-0119-1 (Parallel Operations). [This is
version /01 of this AI - ED.]
This contains the bits that were related to detecting data races and
deadlocking issues relating to blocking calls for parallel constructs.
The wording hasn't change on this, but it probably needs a bit of work to
better define what checks are performed, when they are performed, and how
those checks can be enabled/disabled.
From: Tucker Taft
Sent: Wednesday, March 28, 2018 3:07 PM
We might want to have these rules be associated with a restriction or
restrictions, rather than as basic legality rules. Erhard makes a strong
case for allowing programmers to bypass these rules when appropriate. Randy
argues for introducing the notion of an "Allowance" and making these in effect
unless an Allowance overrules them. In any case, to provide finer control, we
might want to have some way to turn them on and off, which might argue for
both a restriction and an allowance, with "No_Data_Races" and
"Allow_Data_Races" (though that name is a bit strange). Perhaps we just need
a way to locally disable a restriction, e.g.: Pragma
Bypass_Restrictions("No_Data_Races"), analogous to Unsuppress. We already
have a way to specify a restriction partition wide, and implementations could
choose to provide certain restrictions by default, so that seems like an
alternative to having to introduce the distinct concept of allowances. In
particular, support for Annex H might require that certain restrictions be on
by default, but then we clearly would need a way to turn them off.
Also, you seem to have left these rules in the basic AI on parallel
operations. They should probably be removed from there.
Questions? Ask the ACAA Technical Agent