<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Helvetica, Arial, sans-serif">How would a external
      entity notice that there were multiple writes?<br>
      <br>
      <br>
      Alex<br>
      <br>
    </font>
    <div class="moz-cite-prefix">On 17/04/2013 18:18, Vitaly Davidovich
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAHjP37HS70CLh8efBkE2L3n52H86LJxtRqudy2iEKUMO4sRqmA@mail.gmail.com"
      type="cite">
      <p dir="ltr">Yes, but where does it say that #4 is valid and under
        what conditions? Presumably in this example, shared is read
        somewhere else as well (different method perhaps) - else why are
        we calling it shared? Only writers? That's uninteresting.</p>
      <p dir="ltr">Sent from my phone</p>
      <div class="gmail_quot<blockquote class=" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div bgcolor="#FFFFFF" text="#000000"> Yes.<br>
          <br>
          1. Unroll the loop.<br>
          2. Reorder non-volatile accesses to go ahead of volatile
          stores<br>
          3. Now all volatile stores from all iterations are one after
          the other<br>
          4. Multiple stores to the same location can be fused, even if
          they are volatile stores<br>
          <br>
          If you want a store in every iteration, need a volatile load
          somewhere between the stores.<br>
          <br>
          Alex<br>
          <br>
          <br>
          <div>On 17/04/2013 18:01, Vitaly Davidovich wrote:<br>
          </div>
          <blockquote type="cite">
            <p dir="ltr">Are you sure about fusion if shared is
              volatile? Maybe theoretically it's possible but the
              analysis (and risk) the JVM would have to do to make that
              transform is probably impractical.  Intuitively, if I mark
              something volatile, I expect almost verbatim code to
              execute.</p>
            <p dir="ltr">By instructions, I mean loads and stores since
              that's what actually matters for these scenarios.</p>
            <div class="gmail_quote">On Apr 17, 2013 12:55 PM,
              "oleksandr otenko" <<a moz-do-not-send="true"
                href="mailto:oleksandr.otenko@oracle.com"
                target="_blank">oleksandr.otenko@oracle.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 bgcolor="#FFFFFF" text="#000000"> Yes, but not any
                  instructions - only those that have temporal
                  relationship.<br>
                  <br>
                  So, for example, in this case even if shared is
                  volatile, then volatile stores can still be moved out
                  of the loop and fused into a single volatile store.<br>
                  <br>
                  Alex<br>
                  <br>
                  <br>
                  <div>On 17/04/2013 17:43, Vitaly Davidovich wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <p dir="ltr">Immediate means store is made globally
                      visible before subsequent instructions
                      complete/retire.</p>
                    <div class="gmail_quote">On Apr 17, 2013 12:26 PM,
                      "oleksandr otenko" <<a moz-do-not-send="true"
                        href="mailto:oleksandr.otenko@oracle.com"
                        target="_blank">oleksandr.otenko@oracle.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 bgcolor="#FFFFFF" text="#000000"> <font
                            face="Helvetica, Arial, sans-serif">What is
                            this "immediate" anyway?<br>
                            <br>
                            It is actually "before anything else in this
                            thread that's temporal"<br>
                            <br>
                            Alex<br>
                            <br>
                            <br>
                          </font>
                          <div>On 17/04/2013 16:44, Vitaly Davidovich
                            wrote:<br>
                          </div>
                          <blockquote type="cite">
                            <p dir="ltr">I actually expect that the
                              optimizer *would* do this transformation
                              on plain fields (provided it doesn't break
                              intra-thread semantics, of course) because
                              it's a perf gain.</p>
                            <p dir="ltr">Don't know how much JIT can see
                              through println as it ultimately calls
                              into runtime and OS functions, so I'd
                              guess it doesn't know enough or simply
                              plays conservative here.  However,
                              Nathan's point is still valid even if
                              example isn't necessarily the best one. 
                              If you had "pure" java code instead of an
                              I/O call that took significant time to
                              execute, the write would be delayed.  I'm
                              not sure why that matters though for
                              benign data races.  Clearly if you need
                              immediate visibility, you code for that
                              specifically.</p>
                            <div class="gmail_quote">On Apr 17, 2013
                              11:32 AM, "Zhong Yu" <<a
                                moz-do-not-send="true"
                                href="mailto:zhong.j.yu@gmail.com"
                                target="_blank">zhong.j.yu@gmail.com</a>>

                              wrote:<br type="attribution">
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex"> On Wed,
                                Apr 17, 2013 at 1:38 AM, Nathan Reynolds<br>
                                <<a moz-do-not-send="true"
                                  href="mailto:nathan.reynolds@oracle.com"
                                  target="_blank">nathan.reynolds@oracle.com</a>>


                                wrote:<br>
                                > Couldn't JIT hoist the non-volatile
                                writes out of the loop?<br>
                                <br>
                                Certainly, sorry if my statement sounds
                                too absolute.<br>
                                <br>
                                > For example, the following code...<br>
                                <br>
                                But, is this a valid example? Can JMM
                                really reorder around<br>
                                System.out.println()?<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>
                                > Nathan Reynolds | Architect | <a
                                  moz-do-not-send="true"
                                  href="tel:602.333.9091"
                                  value="+16023339091" target="_blank">602.333.9091</a><br>
                                > Oracle PSR Engineering | Server
                                Technology<br>
                                > On 4/16/2013 10:27 PM, Zhong Yu
                                wrote:<br>
                                ><br>
                                > On Tue, Apr 16, 2013 at 8:51 PM,
                                thurstonn <<a moz-do-not-send="true"
href="mailto:thurston@nomagicsoftware.com" target="_blank">thurston@nomagicsoftware.com</a>><br>
                                > wrote:<br>
                                ><br>
                                > Vitaly Davidovich wrote<br>
                                ><br>
                                > The code works as-is.<br>
                                ><br>
                                > Absolutely.  volatile is not needed
                                for correctness<br>
                                ><br>
                                > Vitaly Davidovich wrote<br>
                                ><br>
                                > Why?<br>
                                ><br>
                                > Well, for performance reasons given
                                the 'undefined/indefinite' visibility of<br>
                                > #hash to other threads.<br>
                                > At least according to the JMM
                                (which has nothing to say about CPU
                                cache<br>
                                > coherency), it is *possible* that
                                each distinct thread that invoked<br>
                                > #hashCode() *could* result in a
                                recalculation of the hash.<br>
                                ><br>
                                > In practice though, application
                                threads contain very frequent<br>
                                > synchronization actions, or other
                                operations that force VM to<br>
                                > flush/reload. So it won't take very
                                long for any non-volatile write in<br>
                                > one thread to become visible to
                                other threads.<br>
                                ><br>
                                > Imagine a long-lived Map<String,
                                ?>; and many threads accessing the
                                map's<br>
                                > keyset and for some unknown reason
                                invoking #hashCode() on each key.<br>
                                > If #hash was declared volatile,
                                although there is no guarantee that
                                #hash<br>
                                > would only be calculated once, it
                                is guaranteed that once a write to main<br>
                                > memory was completed, every
                                *subsequent* (here meaning after the
                                write to<br>
                                ><br>
                                > In JMM though, we cannot even
                                express this guarantee. Say we have<br>
                                > threads T1...Tn, each thread Ti
                                burns `i` seconds CPU time first, then<br>
                                > volatile-reads #hash, and if it's
                                0, calculates and volatile-writes<br>
                                > #hash which takes 100 ns. We can
                                find no guarantee from JMM that<br>
                                > there's only one write; it's legal
                                that every thread sees 0 from the<br>
                                > volatile read.<br>
                                ><br>
                                > Zhong Yu<br>
                                ><br>
                                > main memory) read no matter from
                                which thread would see #hash != 0 and<br>
                                > therefore skip the calculation.<br>
                                ><br>
                                ><br>
                                ><br>
                                > Vitaly Davidovich wrote<br>
                                ><br>
                                > String is too high profile
                                (especially<br>
                                > hashing it) to do the "naive"
                                thing.<br>
                                ><br>
                                > Nothing wrong with being naive;
                                naive can be charming.<br>
                                ><br>
                                ><br>
                                > Vitaly Davidovich wrote<br>
                                ><br>
                                > Also, some architectures pay a<br>
                                > penalty for volatile loads and
                                you'd incur that each time.<br>
                                ><br>
                                > Fair point; the JDK authors only
                                get one shot and they can't assume that<br>
                                > volatile reads are cheap<br>
                                ><br>
                                ><br>
                                ><br>
                                ><br>
                                ><br>
                                > --<br>
                                > View this message in context:<br>
                                > <a moz-do-not-send="true"
href="http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9466.html"
                                  target="_blank">http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9466.html</a><br>
                                > Sent from the JSR166 Concurrency
                                mailing list archive at Nabble.com.<br>
                                >
                                _______________________________________________<br>
                                > Concurrency-interest mailing list<br>
                                > <a moz-do-not-send="true"
                                  href="mailto:Concurrency-interest@cs.oswego.edu"
                                  target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                                > <a moz-do-not-send="true"
                                  href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                                  target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                                ><br>
                                >
                                _______________________________________________<br>
                                > Concurrency-interest mailing list<br>
                                > <a moz-do-not-send="true"
                                  href="mailto:Concurrency-interest@cs.oswego.edu"
                                  target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                                > <a moz-do-not-send="true"
                                  href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                                  target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                                ><br>
                                ><br>
                                ><br>
                                ><br>
                                >
                                _______________________________________________<br>
                                > Concurrency-interest mailing list<br>
                                > <a moz-do-not-send="true"
                                  href="mailto:Concurrency-interest@cs.oswego.edu"
                                  target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                                > <a moz-do-not-send="true"
                                  href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                                  target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                                ><br>
_______________________________________________<br>
                                Concurrency-interest mailing list<br>
                                <a moz-do-not-send="true"
                                  href="mailto:Concurrency-interest@cs.oswego.edu"
                                  target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                                <a moz-do-not-send="true"
                                  href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                                  target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                              </blockquote>
                            </div>
                            <br>
                            <fieldset></fieldset>
                            <br>
                            <pre>_______________________________________________
Concurrency-interest mailing list
<a moz-do-not-send="true" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>
<a moz-do-not-send="true" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
</pre>
                          </blockquote>
                          <br>
                        </div>
                        <br>
                        _______________________________________________<br>
                        Concurrency-interest mailing list<br>
                        <a moz-do-not-send="true"
                          href="mailto:Concurrency-interest@cs.oswego.edu"
                          target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                        <a moz-do-not-send="true"
                          href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                          target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                        <br>
                      </blockquote>
                    </div>
                  </blockquote>
                  <br>
                </div>
                <br>
                _______________________________________________<br>
                Concurrency-interest mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:Concurrency-interest@cs.oswego.edu"
                  target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                <a moz-do-not-send="true"
                  href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
                  target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                <br>
              </blockquote>
            </div>
          </blockquote>
          <br>
        </div>
        <br>
        _______________________________________________<br>
        Concurrency-interest mailing list<br>
        <a moz-do-not-send="true"
          href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
        <a moz-do-not-send="true"
          href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest"
          target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>