[concurrency-interest] Can a volatile read be reordered before a lazySet?
tkountis at gmail.com
Sat Dec 27 10:04:02 EST 2014
That cup of coffee must have been really good ;)
Thanks for the detailed explanation Nitsan, especially for that last piece
with the while-loop!
On Sat, Dec 27, 2014 at 8: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.
Q: "Whats the object-oriented way to become wealthy?"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest