Re: Portable memory barrier?

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

"Robert Eachus" <rieachus@comcast.net> wrote in message 
news:df31d3f8-636f-4702-affe-d5a0aa0c898a@googlegroups.com...
On Tuesday, May 9, 2017 at 3:57:50 PM UTC-4, Randy Brukardt wrote:
> "Robert Eachus" <rieachus@comcast.net> wrote in message
> news:077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com...
> ...
>> >The compiler will play some games, and certainly will leave Write_Index 
>> >in
>> >a register if possible.
>>
>> It better not is Write_Index is Atomic.
>
>First, if FIFO has Atomic_Components, then it is not possible. 
>Atomic_Components would be
>overkill, but I haven't seen those declarations here.  If FIFO has just 
>Volatile_Components (or
>no attribute) then this is possible.  But what is "this"?

????

Write_Index needs to be atomic in order for the OP's algorithm to work. 
Atomic objects fall under C.6(20/5) -- all reads and updates are included in 
the external effect of the program. Optimizing them out (in any way) is 
wrong (excepting of course a true as-if optimization, but that doesn't make 
any sense in this case). In particular, saving the value in a register is 
useless, because you still have to read the object again at the next 
reference.

>Sloppy wording, I should have said "keep a copy of Write_Index".  The write 
>to Write_Index
>will occur to cache on modern systems where the whole system is 
>cache-coherent.  But that is
>a detail.  What I was specifically referring to was that there are two 
>subexpressions
>Write_Index+1.  As far as I can tell, if there are no synchronization 
>points between them, the
>(overall system including) the compiler can do one read of Write_Index, 
>then evaluate the
>expression once--or twice.

Definitely not (again assuming Write_Index is atomic). One has to make the 
reads of memory for an atomic object, saving copies is wrong. And there is 
no real value to eliminating the +1 -- in-register operations are 
essentially free on modern architechtures.

Since the rest of your discussion is based on an incorrect premise, I'm 
going to skip it. (Other than to say, if you need the fastest possible code, 
don't make anything volatile or atomic! They're for synchronization, which 
necessarily is going to be slower than the usual code, since it has to be 
predictable.)

...
>> Only the compiler vendor need worry about this level of discussion.
>> Honestly, I doubt anyone else is qualified. (I'm not, and I AM a compiler
>> vendor... ;-)
>
>I used to be a compiler writer, on at least three Ada compilers, but the 
>deep level
>understanding of what is going on comes from my work on radar systems. 
>There
>access times in microseconds are important, and sometimes in nanoseconds. 
>(I think
>the worst real-time requirement I ever saw was for 200 nanoseconds. Ouch!)

I know that (and so am I), but my complaint was that the discussion isn't 
helpful to the OPs question (which is how to do this in hopefully portable 
Ada); it's the compiler's job to get this right and one hopes that the only 
time anyone needs to worry about this is if they have a bug that they think 
is caused by the compiler doing this wrong. (And this is when AdaCore 
support contracts pay for themselves, because you can dump the problem on 
them and let them figure it out. And it's the sort of problem that makes 
those contracts so expensive, because it is HARD work!!)

                               Randy.