[concurrency-interest] Can a volatile read be reordered before a lazySet?

Vitaly Davidovich vitalyd at gmail.com
Sat Dec 27 14:37:27 EST 2014


Nitsan,

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:
>   theLong.lazySet(1L);
>   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)
> <http://shipilev.net/blog/2014/jmm-pragmatics/#_jmm_interpretation_roach_motel>
>
>
> [image: image]
> <http://shipilev.net/blog/2014/jmm-pragmatics/#_jmm_interpretation_roach_motel>
>
>
>
>
>
> Java Memory Model Pragmatics (transcript)
> <http://shipilev.net/blog/2014/jmm-pragmatics/#_jmm_interpretation_roach_motel>
> 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
> <http://shipilev.net/blog/2014/jmm-pragmatics/#_jmm_interpretation_roach_motel>
> 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...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141227/28079660/attachment.html>


More information about the Concurrency-interest mailing list