[concurrency-interest] Can a volatile read be reordered before a lazySet?
vitalyd at gmail.com
Sat Dec 27 14:37:27 EST 2014
In #1, what do you mean exactly by "IIUC this means stores and volatile
loads are conservatively not reordered"? Are you talking about JIT code
motion only? Specifically, I'm pretty sure theLong.lazySet(1); Object o =
theRef.get() sequence compiles to machine code with no cpu fences on x86;
it's a mov immediate into theLong and a mov of theRef into register; the
cpu can reorder these (without a StoreLoad in-between).
On Sat, Dec 27, 2014 at 3:09 AM, Nitsan Wakart <nitsanw at yahoo.com> wrote:
> Saturday morning first cup of coffee 2 cents. T&C apply.
> 1. In this case:
> Object o = theRef.get();
> There's technically nothing to stop reordering between the store and load.
> The problem is that moving the store past the load has potential
> implications to other sequences of stores to theLong/theObject which might
> race with the above. This is described in Shipilev's excellent JMM notes
> here: Java Memory Model Pragmatics (transcript)
> [image: image]
> Java Memory Model Pragmatics (transcript)
> Happens-Before While providing a good basis to reason about programs, SO
> is not enough to construct a practical weak model. Here is why. Let us
> analyze a simple cas...
> View on shipilev.net
> Preview by Yahoo
> IIUC this means stores and volatile loads are conservatively not reordered.
> 2. The case you quote has a further volatile read, we can break it down as:
> long l = theLong.get() + 1; // LOADLOAD
> theLong.lazySet(l); //STORESTORE
> Object o = theRef.get(); // LOADLOAD
> In this case the STORE has to happen after the first load. The first load
> also must happen before the second load. The store can be reordered to
> happen after the second load though (at least in theory, but it won't due
> to 1).
> 3. The ping pong case is different, because the while loops are of
> indefinite length, potentially infinite. Delaying the store indefinitely
> would seem to break sequential consistency and so the while loop acts as an
> effective store barrier. If you replace the while loop with a for(int
> i=0;i<K;i++) loop the reordering becomes notionally feasible again.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest