Version 1.2 of ai12s/ai12-0267-1.txt

Unformatted version of ai12s/ai12-0267-1.txt version 1.2
Other versions for file ai12s/ai12-0267-1.txt

!standard 5.5(6/5)          18-03-29 AI12-0267-1/01
!standard 5.5(9/4)
!standard 5.6.1(0)
!class Amendment 18-03-29
!status work item 18-03-29
!status received 18-03-29
!priority Medium
!difficulty Hard
!subject Data race and non-blocking checks for explicit parallelism
!summary
Data race and non-blocking checks for explicit parallelism are defined. Mechanisms to enable and disable these checks are provided.
!problem
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.
!proposal
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 overlap.
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.
!wording
Add after 5.5(6/5)
{Legality Rules}
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.
AARM Reason: 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
Legality Rules
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)
Loop_Parameter_Check
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.
!discussion
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.
!ASIS
** TBD.
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are supported.
!appendix

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.

****************************************************************

From: Randy Brukardt
Sent: Thursday, March 29, 2018  3:07 PM

One thing that is clearly missing from this AI is a statement that it depends 
on AI12-0119-1 (parallel blocks and loops) and probably on AI12-0242-1
(reduction). It does mention the contract AIs (64 & 79) so it's odd to not
mention the AIs that it is adding Legality Rules too.

****************************************************************

Questions? Ask the ACAA Technical Agent