<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Ah, sorry, I was confused by the possible absence of synchronizes-with edges: the actions alone are enough for 17.4.4 to mandate that volatile accesses of any kind may not be reordered. But the good thing is that I looked at the JVM spec again, which states this very clearly in section 8.7.</div><div><br></div><div>Sorry for the noise,</div><div><br></div><div>Roland</div><div><br></div><div>On Dec 10, 2011, at 23:51 , Joe Bowbeer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">By the way, the paragraph regarding synchronization actions and ordering was cobbled together from sentences in the JMM spec:<div><br></div><div><a href="http://java.sun.com/docs/books/jls/third_edition/html/memory.html">http://java.sun.com/docs/books/jls/third_edition/html/memory.html</a><br>
<br><div class="gmail_quote">If the JMM were purely sequentially consistent then every action could be viewed as a synchronization action.  And declaring all variables as volatile is one (horrible) way to ensure this.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Sat, Dec 10, 2011 at 2:32 PM, Joe Bowbeer wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Volatile read/write is a synchronization action.  A synchronization order is a total order over all of the synchronization actions of an execution.  For each thread t, the synchronization order of the synchronization actions in t is consistent with the program order of t.<div>

<div><br></div><a href="http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile" target="_blank">http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile</a><br><br><div class="gmail_quote">On Sat, Dec 10, 2011 at 2:11 PM, Roland Kuhn wrote:<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Is the compiler not free to re-order the two statements in each thread? They do not depend on each other and volatile does not add anything that I can see: volatile writes may not be moved “earlier” across other writes and volatile reads may not be moved “later” across other reads. And of course a read of one variable may not be moved “earlier” across a write to that variable. But none of the forbidden things is necessary to break this, or am I missing something?</div>

<br><div><div><div><div>On Dec 10, 2011, at 23:01 , Joe Bowbeer wrote:</div><br></div></div><blockquote type="cite"><div><div>Making all variables volatile should force sequentially consistent execution over all, and program-order execution in each thread.<br>

<br>I think it's reasonable to model ConcurrentMap as having a separate lock or volatile per cell, even though in practice the locks are striped.  Is the CM spec even less constrained than this?<div>

<div><br></div><div>On Sat, Dec 10, 2011 at 12:53 PM, Roland Kuhn wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I do not fully understand what you want to demonstrate here wrt. synchronization order; allow me to rephrase with volatile vars:</div>
<br>
Thread 1:<br>
A) a = 1;<br>
B) r1 = b;<br>
<br>
Thread 2:<br>
C) b = 1;<br>
D) r2 = a;<br>
<br>
If I read the spec correctly, the following synchronization order would be consistent:<br>
<br>
start -> r.b -> r.a -> w.a -> w.b -> stop<br>
<br>
There are no synchronizes-with relations in here, and the only happens-before relations are between start and each read and between each write and stop, respectively.<br>
<br>
There is no write where a following read sees a write which sw/hb the write. Intra-thread semantics do not add anything since the write and the read in each thread are not related.<br>
<div><br>
> Can I get r1 = r2 = "0"?  Presumably not.<br>
><br>
</div>Well, please correct my reasoning above, but I think it would be legal. And if it would be legal for volatile vars, why should it not be for CHMs?<br>
<br>
Regards,<br>
<br>
Roland<br>
<div><div><br></div></div></blockquote></div></div></div></div></div></blockquote></div><span><font color="#888888"><br></font></span></div></blockquote></div></div><br></div>
</blockquote></div><br></div>
_______________________________________________<br>Concurrency-interest mailing list<br><a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>http://cs.oswego.edu/mailman/listinfo/concurrency-interest<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">--</div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">[scala-debate on 2009/10/2]<br>Viktor Klang: When will the days of numerical overflow be gone?<br>Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038<br></div></span></span>
</div>
<br></body></html>