<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Couldn't JIT hoist the non-volatile
      writes out of the loop?  For example, the following code...<br>
      <br>
      for (i = 0; i < 1_000_000_000; i++)<br>
      {<br>
          System.out.println(i);<br>
          shared = 2 * i;<br>
      }<br>
      <br>
      ... could be transformed into ...<br>
      <br>
      for (i = 0; i < 1_000_000_000; i++)<br>
      {<br>
          System.out.println(i);<br>
      }<br>
      <br>
      shared = 2 * 1_000_000_000;<br>
      <br>
      ... If so, then the non-volatile write may not happen for a very
      long time.<br>
      <br>
      <div class="moz-signature"><a
          href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds">Nathan
          Reynolds</a> | Architect | 602.333.9091<br>
        <font color="red">Oracle</font> <a
          href="http://psr.us.oracle.com/">PSR Engineering</a> | Server
        Technology<br>
      </div>
      On 4/16/2013 10:27 PM, Zhong Yu wrote:<br>
    </div>
    <blockquote
cite="mid:CACuKZqFZjpLYXcV2xYfhDTaQXNAh9RdAun=g4AxOSq2tZCJPtw@mail.gmail.com"
      type="cite">
      <pre wrap="">On Tue, Apr 16, 2013 at 8:51 PM, thurstonn <a class="moz-txt-link-rfc2396E" href="mailto:thurston@nomagicsoftware.com"><thurston@nomagicsoftware.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Vitaly Davidovich wrote
</pre>
        <blockquote type="cite">
          <pre wrap="">The code works as-is.
</pre>
        </blockquote>
        <pre wrap="">
Absolutely.  volatile is not needed for correctness

Vitaly Davidovich wrote
</pre>
        <blockquote type="cite">
          <pre wrap="">Why?
</pre>
        </blockquote>
        <pre wrap="">
Well, for performance reasons given the 'undefined/indefinite' visibility of
#hash to other threads.
At least according to the JMM (which has nothing to say about CPU cache
coherency), it is *possible* that each distinct thread that invoked
#hashCode() *could* result in a recalculation of the hash.
</pre>
      </blockquote>
      <pre wrap="">
In practice though, application threads contain very frequent
synchronization actions, or other operations that force VM to
flush/reload. So it won't take very long for any non-volatile write in
one thread to become visible to other threads.</pre>
    </blockquote>
    <blockquote
cite="mid:CACuKZqFZjpLYXcV2xYfhDTaQXNAh9RdAun=g4AxOSq2tZCJPtw@mail.gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">Imagine a long-lived Map<String, ?>; and many threads accessing the map's
keyset and for some unknown reason invoking #hashCode() on each key.
If #hash was declared volatile, although there is no guarantee that #hash
would only be calculated once, it is guaranteed that once a write to main
memory was completed, every *subsequent* (here meaning after the write to
</pre>
      </blockquote>
      <pre wrap="">
In JMM though, we cannot even express this guarantee. Say we have
threads T1...Tn, each thread Ti burns `i` seconds CPU time first, then
volatile-reads #hash, and if it's 0, calculates and volatile-writes
#hash which takes 100 ns. We can find no guarantee from JMM that
there's only one write; it's legal that every thread sees 0 from the
volatile read.

Zhong Yu

</pre>
      <blockquote type="cite">
        <pre wrap="">main memory) read no matter from which thread would see #hash != 0 and
therefore skip the calculation.



Vitaly Davidovich wrote
</pre>
        <blockquote type="cite">
          <pre wrap="">String is too high profile (especially
hashing it) to do the "naive" thing.
</pre>
        </blockquote>
        <pre wrap="">
Nothing wrong with being naive; naive can be charming.


Vitaly Davidovich wrote
</pre>
        <blockquote type="cite">
          <pre wrap="">Also, some architectures pay a
penalty for volatile loads and you'd incur that each time.
</pre>
        </blockquote>
        <pre wrap="">
Fair point; the JDK authors only get one shot and they can't assume that
volatile reads are cheap





--
View this message in context: <a class="moz-txt-link-freetext" href="http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9466.html">http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9466.html</a>
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a>
<a class="moz-txt-link-freetext" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
</pre>
      </blockquote>
      <pre wrap="">_______________________________________________
Concurrency-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a>
<a class="moz-txt-link-freetext" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>


</pre>
    </blockquote>
    <br>
  </body>
</html>