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
