Ada Conformity Assessment Authority      Home Conformity Assessment   Test Suite ARGAda Standard
Overview of Ada 2022
Jeff Cousins
Contents   Index   Search   Previous   Next 

2.2 Nonblocking and data race checks

Data race and non-blocking checks for parallel constructs (AI12-0267), amended by Revise the conflict check policies to ensure compatibility (AI12-0298), provides the rules to check for blocking operations and for race conditions within parallel constructs. A “data race” occurs when two concurrent activities attempt to access the same data object without appropriate synchronization and at least one of the accesses updates the object. Such “conflicting” concurrent activities are considered erroneous. The first AI introduces the notion of Conflict Check policies (see RM 9.10.1), to control the degree of checking for potential data races.
It is important that the default for the new parallel constructs is that all possible conflicts are checked, but for backward compatibility we want the default for tasking constructs to be no checks. Thus the pragma Conflict_Check_Policy permits two separate policies, one for parallel constructs, and one for tasking. The policies for parallel constructs include: 
and similarly the policies for tasking include: 
The default policy is: 
pragma Conflict_Check_Policy
If the checking policies for parallel constructs and tasking are the same then the pragma may just take one parameter, thus: 
pragma Conflict_Check_Policy (No_Conflict_Checks);
which is shorthand for: 
pragma Conflict_Check_Policy
Similarly for the policies Known_Conflict_Checks and All_Conflict_Checks.
Procedural iterator aspects (AI12-0344) adds aspect Parallel_Calls to indicate that a subprogram is intended to be called safely from a parallel context, and asks that this is checked in accordance with the Conflict_Check_Policy that is in effect.

Contents   Index   Search   Previous   Next 
© 2021, 2022 Jeff Cousins