[concurrency-interest] DCL using Fence Intrinsics

vikas vikas.vksingh at gmail.com
Fri Mar 13 13:27:43 EDT 2015


Thanks Vitaly,

and sorry for the improper formatting.

on the second note i was wondering why i wouldn't need loadFence in *Code1*
DCL Example

JMM cookbook suggest to insert LoadLoad barrier before final field access
(in processor where data dependency is not respected), my example of DCL
added LoadFence only because of this.

Also C++ example does need both the fences 
http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/

I can think of one reason on why It may work in java without LoadFence is
benign data race-like construct
are kind of allowed in Java whereas they are not allowed in C++.

Also so below *Code4* works for DCL Singleton pattern ?


                                                    *Code4*
  
     sun.misc.Unsafe *U*; 
     Singleton instance = null 

     Singleton getInstance() { 
          Singleton tmp = instance;  // no fence while reading 
          if(tmp == null) { 
              synchronized(Singleton.class) { 
                   tmp = instance; 
                   if(tmp == null) { 
                       tmp = new Singleton(); 
                      * U.storeFence();* // only need StoreFence
                       instance = tmp; 
                  } 
              } 
           } 
       return tmp; 
     } 


 





--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/DCL-using-Fence-Intrinsics-tp12420p12435.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.


More information about the Concurrency-interest mailing list