<p dir="ltr">The Intel spec update is to account for store buffers in the absence of fences.</p>
<p dir="ltr">In your "inserts a Rv0" example aren't we back to scheduling? There's no happens before relationship between the time value and the two other threads.  Making the time writes volatile translates into those writes being visible to all other cores before the time thread progresses - when that time value is observed is up to those other cores.  If the two threads communicated via piggybacking on the time value, say writer writes Svar=9 only when t=9 then reader is guaranteed to see at least Svar=9 if they also see t=9 (on x86), assuming Svar is volatile.  But as your example stands, you have some value being written globally every so often, and then two other threads peeking and poking at it while doing their own thing.</p>
<p dir="ltr">sent from my phone</p>
<div class="gmail_quote">On Mar 17, 2015 10:03 AM, "Marko Topolnik" <<a href="mailto:marko@hazelcast.com">marko@hazelcast.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 17, 2015 at 11:46 AM, Aleksey Shipilev <span dir="ltr"><<a href="mailto:aleksey.shipilev@oracle.com" target="_blank">aleksey.shipilev@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 17.03.2015 9:31, Marko Topolnik wrote:<br>
> There is another concern that may be interesting to reconsider. Given<br>
> the lack of total sync order when just using memory barriers, is the<br>
> JSR-133 Cookbook wrong/outdated in this respect? It doesn't at all deal<br>
> with the issue of the sync order, just with the visibility of<br>
> inter-thread actions.<br>
<br></span>The mental model I am having in my head is as follows:<br>
<br>
  a) Cache-coherent systems maintain the consistent (coherent) view of<br>
each memory location at any given moment. In fact, most coherency<br>
protocols provide the total order for the operations on a *single*<br>
location. Regardless how the actual interconnect is operating, the cache<br>
coherency protocols are to maintain that illusion. MESI-like protocols<br>
are by nature message-based, and so they do not require shared bus to<br>
begin with, so no problems with QPI.<br></blockquote><div><br></div><div>So let's fix the following total order on currentTime:</div><div><br></div><div>T3 -> Rwt3 -> T6 -> Rwt6 -> Rrt6 -> T9 -> Rrt9</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If "sharedVar" is also volatile (sequentially consistent), then Wv1<br>
would complete before reading Rwt6. </blockquote><div><br></div><div>OK, but this wouldn't necessarily happen on a unique global timescale: the "writing" thread would have the ordering Wv1 -> Rwt6; there would be an _independent_ total order of actions on currentTime, and a third, again independent order of actions by the "reading" thread. Due to the distributed nature of coherence the fact that, on one core, Wv1 precedes Rwt6 does not enforce Rrt6 -> Rv1 on another core. It is not obvious that there is transitivity between these individual orders.</div><div><br></div><div>Particularly note this statement in <a href="http://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf" target="_blank">http://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf</a>:</div><div><br></div><div>"[the CPU vendor specifications] admit the IRIW behaviour above but, under
reasonable assumptions on the strongest x86 memory barrier,
MFENCE, adding MFENCEs would not suffice to recover
sequential consistency (instead, one would have to make liberal
use of x86 LOCK’d instructions). Here the
specifications seem to be much looser than the behaviour of
implemented processors: to the best of our knowledge, and
following some testing, IRIW is not observable in practice,
even without MFENCEs. It appears that some JVM implementations
depend on this fact, and would not be correct
if one assumed only the IWP/AMD3.14/x86-CC architecture."</div><div><br></div><div>Also, for the newer revision of Intel's specification, “P6. In a multiprocessor system, stores to the
same location have a total order” has been replaced by: “Any
two stores are seen in a consistent order by processors other
than those performing the stores.”</div><div><br></div><div>So here's a consistent order seen by all the processors except those running the two writing threads:</div><div><br></div><div>Wv0 -> T3 -> T6 -> T9 -> Wv1</div><div><br></div><div>This also respects the total ordering for each individual site, and a total ordering of each individual processor's stores. The "reading" thread inserts its Rv0 between T9 and Wv1.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Reading Rwt6 after the write means<br>
the write is observable near tick 6: it is plausible the clock ticked 6<br>
before we were writing; it is plausible the clock ticked 6 right after<br>
we did the write. Which *really* means the write is guaranteed to be<br>
observable at the *next* tick, T9, since "currentTime" reads/writes are<br>
totally ordered. Therefore, once the reader thread observed t=9, it<br>
should also observe the Wv1, rendering Rv0 reading "0" incorrect.<br>
<br>
                                Rrt9 ---> Rv0<br>
  Wv0 --> Wv1 --> Rwt6           ^<br>
         .---------^         .---/<br>
       T6 ---------------> T9<br>
<br>
 "global time" --------------------------------><br>
<br>
<br>
Notice how this relies on the writer thread to observe Rwt6! That's a<br>
reference frame for you. If writer was to observe Rwt9, you might have<br>
plausibly inferred the Wv1 may be not visible at Rv0:<br></blockquote><div><br></div><div>Thanks, that was precisely my motivation to add Rwt6 :)</div><div> </div><div>---</div><div>Marko</div></div></div></div>
<br>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br></blockquote></div>