Re: Portable memory barrier?

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

On Wednesday, May 10, 2017 at 3:13:27 AM UTC-4, Dmitry A. Kazakov wrote:
> On 10/05/2017 02:51, 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?
> 
> But you don't need elements atomic only index has to. If I understood 
> Randy's explanation correctly atomic access to the buffer index will 
> give you the barrier between index and element accesses which is all 
> that is required.

I may have misunderstood him, but from Randy's response, I gathered that 
Volatile has no effect on sequence, only Atomic does.  My understanding is that 
there are two parts to sequence:  compiler reordering and cpu reordering.  From 
Randy's response I gathered that Atomic guarantees no CPU rerodering between it 
and volatile objects (using fences or whatever mechanism provided).  If Volatile 
has no effect on Compiler reordering sequence, then even if Atomic can put 
fences between it and Volatile objects, if the compiler reorders before that 
happens, the fence won't help.  So I can safely know that the index operations 
are safe, but I don't know if any assignment before or after the indexing operation is ok or not since the buffer is only volatile. 

In particular, I am basing it off of this response from Randy:
***************************************************
(partial quote)
Atomic implies sequential access for atomic AND volatile objects (note that
volatile does NOT imply that). See 9.10 if you dare. (And if you understand
9.10, please join the ARG, we need you. ;-)

In particular, Atomic implies that any needed memory fences are used.
(Again, volatile alone does not make such a requirement.) The idea is that
one uses atomic objects to protect larger volatile data structures.  
***************************************************

So even if Atomic does use fences, if the compiler decides to reorder the 
statements before the binary is created, it my not help.

Did I misunderstand his response?  I might have.

It has been my own experience that GNAT will prevent "compiler" reordering on 
operations on Volatile objects, but that is probably just a GNAT extension.