out by labeling variables [Data]{} and [Flag]{} by aspect [volatile]{}. The corresponding variable declarations are depicted in Fig. \[fig:mem:example\](b). (Note that by [@Ada2012LRM C.6§8/3] aspect [atomic]{} implies aspect [volatile]{}, but not vice versa.)

The intention for volatile variables in Ada 2012 was to guarantee that all tasks agree on the same order of updates [@Ada2012LRM C.6§16/3]. Updates of volatile variables are thus required to be sequentially consistent, in the sense of Lamport’s definition [@Lamport:SC]: “[*With sequential consistency (SC), any execution has a total order over all memory writes and reads, with each read reading from the most recent write to the same location*]{}”.

However, the Ada 2012 aspect [volatile]{} has the following shortcomings:

1.  Ensuring SC for multiple tasks without atomic access is impossible. Non-atomic volatile variables therefore should not be provided by the language. Otherwise, the responsibility shifts from the programming language implementation to the programmer to ensure SC by pairing an atomic (implied volatile) variable with each non-atomic volatile variable (see, e.g., Fig. \[fig:mem:example\](b) and [@Simpson1990] for examples). (Note that a programming language implementation may ensure atomicity by a mutual exclusion lock if no hardware primitives for atomic access to a particular type of shared data are available.)

