Overview of Ada 2022
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:
No_Parallel_Conflict_Checks
Known_Parallel_Conflict_Checks
All_Parallel_Conflict_Checks
and similarly the policies
for tasking include:
No_Tasking_Conflict_Checks
Known_Tasking_Conflict_Checks
All_Tasking_Conflict_Checks.
The default policy is:
pragma Conflict_Check_Policy
(All_Parallel_Conflict_Checks,
No_Tasking_Conflict_Checks);
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
(No_Parallel_Conflict_Checks,
No_Tasking_Conflict_Checks);
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.
© 2021, 2022 Jeff Cousins