[concurrency-interest] DCL using Fence Intrinsics

Vitaly Davidovich vitalyd at gmail.com
Fri Mar 13 14:57:41 EDT 2015


>
> 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.


Right, the only such processor (that doesn't respect indirection) I've
heard of is Alpha, but AFAIK, that's not a supported platform (for Oracle
Hotspot, at least).

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 ?


One aspect is that java disallows introducing phantom reads when you've
loaded a piece of memory into a temp and are using the temp -- C++ allows
for this, which breaks racy attempts that would succeed in java.

I could be wrong, but my thinking is that Code4 is basically what happens
when you invoke a constructor with final fields (as I mentioned before) and
then publish the reference racily.  Technically speaking, if you were to
take things like the Alpha into account, you most definitely would need a
load fence.  The one doubt in my head is in this snippet of your code:

tmp = instance;
                   if(tmp == null) {
                       tmp = new Singleton();
                      * U.storeFence();* // only need StoreFence
                       instance = tmp;
                  }

It's theoretically conceivable for a compiler to realize that it doesn't
need to store to 'tmp' here and just store to the field directly.  If there
were no storeFence() there, then that definitely isn't right (it's
basically the broken DCL scenario).  With the storeFence() placed where it
is, there's a clear (in my mind, at least) barrier between where
allocation+construction is done and field assignment.  If that's true, and
taking things like Alpha out of the equation, I believe you don't need the
loadFence.

On Fri, Mar 13, 2015 at 1:27 PM, vikas <vikas.vksingh at gmail.com> wrote:

> 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.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150313/d6f15abb/attachment.html>


More information about the Concurrency-interest mailing list