<div dir="ltr">I mentioned that in my previous reply, but I'm not aware of any JVM running on platforms that allow such reordering.  I also highly doubt that such a platform would ever be ported to as bug tail would be very long, along with JVM having to insert LoadLoad barriers in lots of places where refs are read of classes with at least one final field.  If you have a concrete/real/practical example of where this reordering can take place, I'd love to know about it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 2:38 PM, Oleksandr Otenko <span dir="ltr"><<a href="mailto:oleksandr.otenko@oracle.com" target="_blank">oleksandr.otenko@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vitaly is wrong. The loadFence in Code1 is needed. Without it, it is possible to access the uninitialized fields of the singleton. (the loads may occur before the load of instance)<br>
<br>
<br>
Alex<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 13/03/2015 17:27, vikas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks Vitaly,<br>
<br>
and sorry for the improper formatting.<br>
<br>
on the second note i was wondering why i wouldn't need loadFence in *Code1*<br>
DCL Example<br>
<br>
JMM cookbook suggest to insert LoadLoad barrier before final field access<br>
(in processor where data dependency is not respected), my example of DCL<br>
added LoadFence only because of this.<br>
<br>
Also C++ example does need both the fences<br>
<a href="http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/" target="_blank">http://preshing.com/20130930/<u></u>double-checked-locking-is-<u></u>fixed-in-cpp11/</a><br>
<br>
I can think of one reason on why It may work in java without LoadFence is<br>
benign data race-like construct<br>
are kind of allowed in Java whereas they are not allowed in C++.<br>
<br>
Also so below *Code4* works for DCL Singleton pattern ?<br>
<br>
<br>
                                                     *Code4*<br>
         sun.misc.Unsafe *U*;<br>
      Singleton instance = null<br>
<br>
      Singleton getInstance() {<br>
           Singleton tmp = instance;  // no fence while reading<br>
           if(tmp == null) {<br>
               synchronized(Singleton.class) {<br>
                    tmp = instance;<br>
                    if(tmp == null) {<br>
                        tmp = new Singleton();<br>
                       * U.storeFence();* // only need StoreFence<br>
                        instance = tmp;<br>
                   }<br>
               }<br>
            }<br>
        return tmp;<br>
      }<br>
<br>
<br>
  <br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://jsr166-concurrency.10961.n7.nabble.com/DCL-using-Fence-Intrinsics-tp12420p12435.html" target="_blank">http://jsr166-concurrency.<u></u>10961.n7.nabble.com/DCL-using-<u></u>Fence-Intrinsics-<u></u>tp12420p12435.html</a><br>
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.<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>
<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>
</div></div></blockquote></div><br></div>