<p>Thanks Doug.</p>
<p>I'm aware that the type of instruction and whether a fence is a no-op is arch specific, but I was curious how the compilers (c1/c2) make decisions around these things,  such as if they track pairs of read/write of same volatile across method bounds ( I believe they don't at the moment).</p>

<div class="gmail_quote">On Oct 10, 2011 9:14 AM, "Doug Lea" <<a href="mailto:dl@cs.oswego.edu">dl@cs.oswego.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/10/11 08:56, Vitaly Davidovich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree that the way StoreLoad is implemented ensures that volatile reads of<br>
 different memory location don't move before the store, but I think the JMM<br>
only talks about needing this for loads of same memory location (see Doug's<br>
cookbook web page description).<br>
</blockquote>
<br>
Additionally, the "synchronization order" (roughly, any trace of<br>
all volatile accesses) is required to be a total order, which<br>
is the main constraint that forces the Dekker example to work.<br>
This is not made clear enough in cookbook, which should be improved.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By the way, would be great if someone from the Hotspot runtime/compiler team<br>
could shed some light on how Hotspot handles these, with the caveat that<br>
people shouldn't necessarily base their code on it if it makes stronger<br>
guarantees than the JMM :).<br>
</blockquote>
<br>
The main visible cases are processor- not JVM- based, and<br>
most are only visible in giving you more consistency than required<br>
for non-volatile accesses. In general, x86 and sparc are<br>
stronger than POWER and ARM, with a few others<br>
(Azul, IA64) in the middle.<br>
<br>
-Doug<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.<u></u>oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/<u></u>listinfo/concurrency-interest</a><br>
</blockquote></div>