[concurrency-interest] DCL using Fence Intrinsics

Oleksandr Otenko oleksandr.otenko at oracle.com
Fri Mar 13 16:22:19 EDT 2015


Wasn't there a recent thread with a reference to a platform which can 
load even dependent data out of order?

http://en.wikipedia.org/wiki/Memory_ordering
>
>   * Dependent loads can be reordered (this is unique for Alpha). If
>     the processor fetches a pointer to some data after this
>     reordering, it might not fetch the data itself but use stale data
>     which it has already cached and not yet invalidated. Allowing this
>     relaxation makes cache hardware simpler and faster but leads to
>     the requirement of memory barriers for readers and writers.^[5]
>     <http://en.wikipedia.org/wiki/Memory_ordering#cite_note-5>
>


Alex

On 13/03/2015 19:31, Vitaly Davidovich wrote:
> 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.
>
> On Fri, Mar 13, 2015 at 2:38 PM, Oleksandr Otenko 
> <oleksandr.otenko at oracle.com <mailto:oleksandr.otenko at oracle.com>> wrote:
>
>     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)
>
>
>     Alex
>
>
>
>     On 13/03/2015 17:27, vikas 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
>         <mailto:Concurrency-interest at cs.oswego.edu>
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto: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/ee0070a3/attachment.html>


More information about the Concurrency-interest mailing list