Re: Portable memory barrier?

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

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 to Holsti for pointing this out [through ARM C.6(20)]. My previous 
understanding of this was incorrect.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09