Re: Portable memory barrier?

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

"Robert Eachus" <rieachus@comcast.net> wrote in message 
news:fcf4a91a-bfdf-44ee-a888-7bb9a1c52b48@googlegroups.com...
On Wednesday, May 10, 2017 at 9:02:22 PM UTC-4, Randy Brukardt wrote:

>> 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.

>Even if there is no intervening read or write of anything?

Yes.

>It seems to me that must be an "as if," since there is no way to prove 
>otherwise.
>You may be thinking of reads of memory external to the CPU, part of some
>other hardware, where the other hardware can intervene.

I'm not "thinking" that, the language defines it that way (it's part of the 
external effect of the program, C.6(20) and 1.1.3(8-14)). I don't know how a 
compiler could possibly know if someone has a way to see the external 
effects (some CPU monitor, active memory, etc.), so one has to assume that 
they CAN tell. And in any case, the intent of the language designers is 
crystal-clear -- ignore that at your peril.

...
>Hmm. You need to read the (x86 and most other) rules for prefetching memory 
>locations.
>As I stated earlier in this thread, any CPU core is allowed to do a 
>prefetch of any location,
>as long as it does not cause an action like an interrupt.  This is 
>necessary, or you wouldn't
>be able to have any Atomic accesses. The CPU reads an entire cache line, 
>usually 64, 128,
>or 256 bytes into the cache, but even the widest of CPU writes are only 64 
>bytes wide, and
>those are multiple floating-point values.

I have the compiler generate the "correct" code and don't worry much about 
what the CPU does to it. (That's one reason I was completely in favor of 
removing the bogus requirement to read/write all the way to memory -- it 
doesn't make sense on CPUs that do caching.) That's out of my hands in any 
case as a software guy. (Refer to my response to Jere.) There's a 
requirement to prevent CPU reordering, but nothing else.

But I wouldn't be implementing the language if I started ignoring the 
requirements on the compiler by leaning on an as-if optimization, especially 
one that can be detected with active hardware. Especially as if I did so, 
there would be no possibility of ever writing portable synchonization 
code...

                                Randy.