JavaMemoryModel: Re: "Double-Checked Locking is Broken"

From: Doug Lea (
Date: Sun Mar 25 2001 - 09:33:00 EST

> i remember reading multiple sources which said that on Sparc
> there is no need for _two_ memory barriers for DCL - so that the
> only MB needed is the one after singleton creation

Right. my results do not indicate impact of read-barriers that would
be needed, for example, on alphas. I don't have access to alpha (or
powerpc or other) MPs, so can't check this. Maybe others can. Alan
MacKinnon did kindly sent results though for a 2-CPU intel x86 box
under hotspot 1.3. Here they are, along with my previous ones, and
also a run on a sparc uniprocessor. I normalized these by dividing
each time by "Eager" case:

                    2-CPU 4-CPU 1-CPU
                    x86 sparc sparc
Eager: 1.00 1.00 1.00
Volatile: 1.31 1.06 1.18
ThreadSpecific: 6.50 4.84 5.01
Synch: 32.12 88.40 9.64

Intels are like sparcs wrt not needing read barriers. But the
"volatile" results here for x86 might be faster than they ought to be
since 1.3 hotspot only partially conformed to "old" volatile rules.

As you'd expect, the synch case gets much worse as you add CPUs. But,
it is not hard to make Synch times vary by a factor of two or more
here just by tweaking thread settings and the like. And, given how
unrealistic and extreme this test is, it is probably not a useful
indication of overall savings in any practical application. Again,
the special-static-class-with-final-static-field idiom described on
is normally the best solution for Singletons anyway in Java. It is
equivalent in performance to the "Eager" case here.

> what are the proposed revised "volatile" semantics

See the descriptions linked off

Note especially that in Java, "volatile" not only ensures the right
barriers, it also suppresses some other optimizations and reorderings
that could break sequential consistency, even on uniprocessors. As
mentioned in one of the postings you forwarded, the lack of memory
models for C/C++ makes it hard/impossible to guarantee that POSIX
versions of your code will work.

> thanks a lot for creating the java version and for performance
> data!! may be you can post it to comp.programming.threads?
> (there is a running thread "DCL -- is there a FAQ?")

Well, I'm not so sure I want to get embroiled in this discussion,
but feel free to include my code or comments.

Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA 315-312-2688 FAX:315-312-5424  
JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT