<div dir="ltr">Vitaly,<div><br></div><div>if you refer back to the diagram, the writer thread:</div><div><br></div><div>1. wrote 0 to the shared var;</div><div>2. observed t = 3ms;</div><div>3. wrote 1 to the shared var;</div><div>4. observed t = 6 ms. </div><div><br></div><div>The reader thread:</div><div>1. observed t = 6 ms;</div><div>2. observed t = 9 ms;</div><div>3. read 0 from the shared var.</div><div><br></div><div>This should eliminate the effects of scheduling.</div><div><br></div><div>The point is, the above is in violation of the Java Memory Model because no total synchronization order is possible under which this result would be obtained. On the other hand, it is happens before-consistent.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 7:35 PM, Vitaly Davidovich <span dir="ltr"><<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Marko,<div><br></div><div>Can't scheduling alone cause a situation where reader reads t=9ms, looks at the shared value, and sees something old that hasn't been updated yet since the writer hasn't observed the t=9ms yet (due to scheduling)? Nehalem is a TSO (total store order) architecture, which means each core's writes appear in the same order to all other cores, but there's no global order across all cores.  So your clock-updating thread's stores will appear to the reader/writer in the same order, but what can reader/writer say about the other if each reads t = X? I think nothing of consequence given they're not synchronizing-with the clock-updating thread, but simply observing that value in a "racy" (with respect to each other) manner.</div><div><br></div><div>I'm probably misunderstanding your question/point though, so please correct me.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Mar 16, 2015 at 1:00 PM, Marko Topolnik <span dir="ltr"><<a href="mailto:marko@hazelcast.com" target="_blank">marko@hazelcast.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">In an old post I drew the diagram below, which showed happens-before edges between three threads. The thread shown at the bottom was a "clock-updating" thread, continuously updating a volatile "current time" value. The other two threads read the time and were additionally coupled through a shared volatile variable with one writer and one reader thread.<div><br></div><div>My point was that the threads could behave in a paradoxical way from the standpoint of "global time": the reader could observe a late time value and nevertheless not be prevented from observing an early write to the shared var.</div><div><br></div><div>The JMM actually prevents this behavior with the enforcement of a total sync order.</div><div><br></div><div>However, during a private discussion with Martin Thompson, it seemed unclear how exactly a runtime would actually enforce total sync order without hurting performance. Given that, since Nehalem, cores communicate point-to-point over QPI and don't lock the global front-side bus, the CPU doesn't naturally offer a total ordering of all lock operations. I would be very interested to learn how exactly this goes on, or perhaps whether Martin and I were missing something and this is actually not an issue.</div><div><br></div><div>Here is the diagram reposted:</div><div><br><br>                                /--> Rrt6 --/-> Rrt9 --> Rv0<br>    ---------------------------+------------+--------/<br>  /                            |     ------/<br>Wv0 ---> Rwt3 -> Wv1 --> Rwt6  |    /<br>        /                /   --|   /<br>       |                | /       /<br>       T3 ------------> T6 ----> T9<br><br><br>T3, T6, T9 -- writes to currentTime<br>Rwt0, Rwt1 -- reads of currentTime by writing thread<br>Rrt1, Rrt2 -- reads of currentTime by reading thread<br>Wv0, Wv1   -- writes to the sharedVar<br>Rv0        -- read of the sharedVar<br><br>initially t = 0 ms;<br>T3 writes t = 3 ms;<br>T6 writes t = 6 ms;<br>T9 writes t = 9 ms.<br><br>The program outputs<br><br>Writing 0 at t = 0 ms<br>Writing 1 at t = 3 ms<br>Reading 0 at t = 9 ms</div><div><br></div><div><div><br>---</div><div>Marko Topolnik</div><div>Hazelcast</div></div><div><br></div></div>
<br></div></div>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">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><br></div>
</blockquote></div><br></div>