Re: Portable memory barrier?

["Randy Brukardt" <randy@rrsoftware.com>]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:36434cd8-bc44-4d4a-957d-987fdf106be7@googlegroups.com...
...
> Thanks for the response!  I'm good with all that.  I'm more worried about
> situations like these:
>
> Task A:
> -- Do some checks to make sure buffer not full
>
> -- Not full, so put data
> My_Array(Put_Index) := Some_Value;
> if Put_Index = Buffer_Size then
>   Put_Index := 0;
> else
>   Put_Index := Put_Index + 1;
> end if;
>
> Task B:
> if Put_Index = Get_Index then -- empty
>   return False;
> end if;
>
> Result_Value := My_Array(Get_Index);
> -- Do other operations that update Get_Index
>
> Assuming the indexes are atomic and volatile, then I am not worried about
> partial writes to the indexes.  I"m more worried about some architectures 
> that
> allow for instruction reordering.

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.

Caveat: that's an untestable requirement, so you're totally at the mercy of 
your compiler vendor to get this right.

                                Randy.

P.S. Yes, we've discussed this in the ARG. We believe the RM description has 
the right effect, but the issues and wording are both hairy, so we could be 
wrong.