Re: should sync builtins be full optimization barriers?

[Andrew MacLeod <amacleod at redhat dot com>]

On 09/12/2011 02:40 PM, Geert Bosch wrote:
> thread 1  thread 2  thread 3  thread 4
> --------  --------  --------  --------
>    x=1;      r1=x      x=3;      r3=x;
>    x=2;      r2=x      x=4;      r4=x;
>
> Even with relaxed memory ordering, all modifications to x have to occur in some particular total order, called  the modification order of x.
>
> So, even if each thread preserves its store order, the modification order of x can be any of:
>    1,2,3,4
>    1,3,2,4
>    1,3,4,2
>    3,1,2,4
>    3,1,4,2
>    3,4,1,2
>
> Because there is a single modification order for x, it would be an error for thread 2 and thread 4 to see a different update order.

Lets simplify it slightly.  The compiler can optimize away x=1 and x=3 
as dead stores (even valid on atomics!), leaving us with 2 modification 
orders..
     2,4 or 4,2
and what you are getting at is you don't think we should ever see
r1==2, r2==4  and r3==4, r4==2

lets say the order of the writes turns out to be  2,4...  is it possible 
for both writes to be travelling around some bus and have thread 4 
actually read the second one first, followed by the first one?   It 
would imply a lack of memory coherency in the system wouldn't it? My 
simple understanding is that the hardware gives us this sort of minimum 
guarantee on all shared memory. which means we should never see that happen.

And if we can't see that, then I don't see how we can see your example.. 
 *one* of those modification orders has to be what is actually written 
to x, and reads from that memory location will not be able to see an 
something else. (ie, if it was 1,2,3,4  then thread 4 would not be able 
to see r3==4,r4==1 thanks to memory coherency.

Andrew