Re: Portable memory barrier?

[Jere <jhb.chat@gmail.com>]

On Wednesday, May 10, 2017 at 12:38:54 PM UTC-4, Jeffrey R. Carter wrote:
> On 05/10/2017 02:51 AM, Jere wrote:
> >
> > Is there a method besides Atomic?  If I am implementing a generic FIFO (lock
> > free) and the FIFO elements are complex data types that may not be able to be
> > atomic, do I have any other options or are protected objects my only way out?
> 
> If your indices are Atomic and your array has Volatile_Components, then I think 
> things will work the way you want them to. The important reference here is ARM 
> 1.1.3, which says
> 
> * Any read or update of an atomic or volatile object is part of the program's 
> external interactions.
> 
> * An Ada compiler must produce a program with external interactions in the order 
> and timing specified by Ada's semantics.
> 
> Ada's semantics for a sequence of statements say the statements are executed in 
> order.
> 
> So, if you have in task A
> 
> A (I + 1) := Item;
> I := I + 1;
> 
> Then from the outside an observer must see in order
> 
> 1. Read I
> 2. Write A (I + 1)
> 3. Read I
> 4. Write I
> 
> If task B does
> 
> if I > 0 then
> 
> then B's "Read I" will also be something the external observer can see. It might 
> happen before 1., between 1. and 3., between 3. and 4., or after 4., but won't 
> happen during any of 1, 3, or 4. That guarantees that B will always get a valid 
> view of I.
Thanks!

My previous couple of emails might be moot now that I have read this response.  
Here I get the impression that Volatile does prevent Compiler statement 
reordering.  If that is the case, then I know between that and any fencing put 
up by Atomic objects will be sufficient.

So at this point my understanding is now:
Type => Prevents Compiler Reordering => Prevents CPU Reordering
Volatile => YES => NO
Atomic   => YES => YES