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

Nitsan Wakart nitsanw at yahoo.com
Sat Dec 27 03:09:59 EST 2014


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)
|   |
|   |  |   |   |   |   |   |
| 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(); // LOADLOADIn 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/032f7a72/attachment.html>


More information about the Concurrency-interest mailing list