<p>By the way, would be great if someone from the Hotspot runtime/compiler team could shed some light on how Hotspot handles these, with the caveat that people shouldn't necessarily base their code on it if it makes stronger guarantees than the JMM :).</p>

<div class="gmail_quote">On Oct 10, 2011 8:56 AM, "Vitaly Davidovich" <<a href="mailto:vitalyd@gmail.com">vitalyd@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Hi Hans,</p>
<p>I agree that the way StoreLoad is implemented ensures that volatile reads of different memory location don't move before the store, but I think the JMM only talks about needing this for loads of same memory location (see Doug's cookbook web page description).  For example, it's known that in order to create a happens-before edge, according to the JMM, by using volatile read/write you have to read/write same volatile.  In practice this probably isn't strictly the case because the JVM doesn't track the "pairs" (I.e. store/load of same volatile across different methods) and thus issues fences strong enough to make this work for unrelated volatile locations.</p>


<p>Please correct me if I'm wrong though.</p>
<p>Thanks</p>
<div class="gmail_quote">On Oct 9, 2011 10:48 PM, "Boehm, Hans" <<a href="mailto:hans.boehm@hp.com" target="_blank">hans.boehm@hp.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I agree with most of this.  However, the reason for the StoreLoad fence following a volatile store is typically  to prevent reordering of the store with a subsequent
 volatile load of a DIFFERENT VOLATILE variable.   For example, consider the standard Dekker’s algorithm example, where everything is initially zero:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Thread 1:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">x = 1;<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">r1 = y;<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Thread 2:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">y = 1;<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">r2 = x;<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">If x and y are volatile, r1 = r2 = 0 is not allowed.  This means that the two accesses in each thread may not be reordered.  My understanding is that if lazySet
 is used here, r1 = r2 = 0 is allowed, and hence the trailing StoreLoad fence is not required.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">A lot of the details here are architecture specific.  In particular, the PowerPC story is quite different and more complicated, since PowerPC doesn’t by default
 guarantee that stores become visible on all other processors at the same time.  Fences are also required to effectively obtain that guarantee.  The difference between lazySet and a volatile store is probably larger on x86 than on most other architectures.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Hans<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Vitaly Davidovich [mailto:<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>]
<br>
<b>Sent:</b> Sunday, October 09, 2011 3:53 PM<br>
<b>To:</b> Ruslan Cheremin<br>
<b>Cc:</b> Boehm, Hans; <a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.oswego.edu</a><br>
<b>Subject:</b> Re: AtomicXXX.lazySet and happens-before reasoning<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">That is not clear for me -- doesn't strict volatile store prevents any reordering with subsequent memory actions? Huns, you've just present an example of such allowed reordering.<u></u><u></u></p>


</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">A volatile store does not prevent subsequent <b>non-volatile</b> store/loads from reordering with it.  A StoreLoad is placed after the volatile store only if followed by a volatile load of the same memory location that was stored (this
 is to avoid the load from being satisfied out of the processor's write buffer before the prior store is made globally visible).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Based on this discussion, it sounds like lazySet does not prevent subsequent instructions from reordering with it.  Specifically, if a lazySet is followed by a volatile load, no StoreLoad is issued in between and the processor can fetch
 the data from the write buffer before other processors see the write; this is the reason that lazySet will be much cheaper than volatile write because it doesn't have to issue a fence instruction here and wait for the store buffer to drain to the cache.  In
 my own observation, lazySet translates to a regular MOV instruction on x86 (64) and a volatile write issues a locked add instruction after the write (or mfence on older Hotspot versions), which obtains the required serialization.<u></u><u></u></p>


</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Sun, Oct 9, 2011 at 6:03 PM, Ruslan Cheremin <<a href="mailto:cheremin@gmail.com" target="_blank">cheremin@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The farther, the better :)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yes, from this atomic package javadoc specification it is clear that it is not only StoreStore, but also LoadStore barriers before lazySet.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Interestingly that my meeting with lazySet started from informal definition like "non-volatile write to volatile variable with few additional ordering constraints", but for now it is "<span style="color:black">has the memory effects of
 writing (assigning) a </span><span style="font-size:10.0pt;font-family:"Courier New";color:black">volatile</span><span style="color:black"> variable except..." </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">That is not clear for me -- doesn't strict volatile store prevents any reordering with subsequent memory actions? Huns, you've just present an example of such allowed reordering.</span><u></u><u></u></p>


</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">It seems like it somekind related to StoreLoad fence which ordinary volatile store must has after it (although I still do not understand why), but lazySet omit?</span><u></u><u></u></p>


</div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> </span><u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">The specification states</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.25in">
<span style="font-size:10.0pt;font-family:Symbol;color:black">·</span><span style="font-size:7.0pt;color:black">        
</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">lazySet</span><span style="color:black"> has the memory effects of writing (assigning) a
</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">volatile</span><span style="color:black"> variable except that it permits reorderings with subsequent (but not previous) memory actions that do not themselves impose reordering constraints
 with ordinary non-</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">volatile</span><span style="color:black"> writes. Among other usage contexts,
</span><span style="font-size:10.0pt;font-family:"Courier New";color:black">lazySet</span><span style="color:black"> may apply when nulling out, for the sake of garbage collection, a reference that is never accessed again.
</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:5.25pt">
<span style="color:black">in the java.util.concurrent description, which implies that it may not be reordered with previous “memory actions”, not just stores.  Doug can comment more authoritatively on the intent, but that specification seems fairly unambiguous
 in this particular respect.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:5.25pt">
<span style="color:black"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:5.25pt">
<span style="color:black">Hans</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:5.25pt">
<span style="color:black"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Vitaly Davidovich [mailto:<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>]
<br>
<b>Sent:</b> Saturday, October 08, 2011 10:11 AM<br>
<b>To:</b> Boehm, Hans; <a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.oswego.edu</a><br>
<b>Subject:</b> Re: [concurrency-interest] AtomicXXX.lazySet and happens-before reasoning</span><u></u><u></u></p>
</div>
</div>
<p> <u></u><u></u></p>
<p style="margin-bottom:12.0pt">+ rest of the group<u></u><u></u></p>
<div>
<p>On Sat, Oct 8, 2011 at 1:10 PM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>> wrote:<u></u><u></u></p>
<p>Hi Hans,<u></u><u></u></p>
<div>
<p> <u></u><u></u></p>
</div>
<div>
<p>I was under the impression that lazySet is purely a StoreStore barrier, and only specifies that the lazySet cannot be reordered with prior writes -- I never saw mention of requiring no reordering with prior loads.  Here's Doug's evaluation: <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6275329" target="_blank">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6275329</a>,
 where only a store-store is mentioned.  If it's really a LoadStore | StoreStore, good to know ...<u></u><u></u></p>
</div>
<div>
<p> <u></u><u></u></p>
</div>
<div>
<p>Thanks<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p> <u></u><u></u></p>
<div>
<p>On Sat, Oct 8, 2011 at 12:06 AM, Boehm, Hans <<a href="mailto:hans.boehm@hp.com" target="_blank">hans.boehm@hp.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p><span style="font-size:11.0pt;color:#1F497D">LazySet() needs to prevent reordering of ordinary memory operations with a subsequent lazySet() operation.  In the JSR 133 Cookbook style, that can be implemented with a LoadStore | StoreStore fence preceding
 the lazySet() call.  So yes, that makes sense.</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p><span style="font-size:11.0pt;color:#1F497D">Real machines tend to require neither of those fences (x86) or combine them into a single instruction.</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p><span style="font-size:11.0pt;color:#1F497D">Hans</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Vitaly Davidovich [mailto:<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>]
<br>
<b>Sent:</b> Friday, October 07, 2011 5:10 PM<br>
<b>To:</b> Boehm, Hans<br>
<b>Cc:</b> <a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.oswego.edu</a>; Ruslan Cheremin</span><u></u><u></u></p>
<div>
<p><br>
<b>Subject:</b> Re: [concurrency-interest] AtomicXXX.lazySet and happens-before reasoning<u></u><u></u></p>
</div>
</div>
</div>
<p> <u></u><u></u></p>
<p>Does it even make sense to say that lazySet needs a LoadStore fence? The get() does but that's because it has same semantics as volatile read.
<u></u><u></u></p>
<div>
<div>
<div>
<p>On Oct 7, 2011 7:29 PM, "Boehm, Hans" <<a href="mailto:hans.boehm@hp.com" target="_blank">hans.boehm@hp.com</a>> wrote:<u></u><u></u></p>
<p>> From: Ruslan Cheremin [mailto:<a href="mailto:cheremin@gmail.com" target="_blank">cheremin@gmail.com</a>]<br>
> > It also needs a LoadStore fence, in both cases.<br>
><br>
> But why lazySet needs LoadStore fence? It seems what lazySet javadoc<br>
> does not put any ordering constraints on loads...<br>
I do read it as imposing such a constraint, though we all agree that a more precise spec would help.  Certainly C++11's memory_order_release imposes such a constraint.<br>
<br>
If not, it would mean that e.g.<br>
<br>
Thread 1:<br>
x = ...;<br>
...<br>
r1 = x;<br>
done_with_x.lazySet(true);<br>
<br>
Thread 2:<br>
if (done_with_x.get()) {<br>
  x = ...;<br>
  ...<br>
  r2 = x;<br>
}<br>
<br>
wouldn't work as expected.<br>
<br>
In my opinion, that's an indefensible design point, especially since I don't believe it makes lazySet appreciably cheaper on any modern architectures.<br>
<br>
<br>
><br>
> > In particular, if v is volatile (and certainly if it's accessed using<br>
> lazySet), and x and y are ordinary variables,<br>
> > then the assignments to x and y in the following may be visibly<br>
> reordered:<br>
> > x = 1;<br>
> > v = 2;<br>
> > y = 3;<br>
><br>
> You mean what vstore is not "transparent" upside down, but<br>
> "transparent" downside up, so this<br>
><br>
> y=3<br>
> x=1<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <br>
Vitaly<br>
<a href="tel:617-548-7007" value="+16175487007" target="_blank">617-548-7007</a> (mobile)<u></u><u></u></p>
</div>
</div>
</div>

</blockquote></div>
</blockquote></div>