[concurrency-interest] Double Checked Locking in OpenJDK

Doug Lea dl at cs.oswego.edu
Thu Aug 16 06:25:00 EDT 2012


On 08/16/12 02:10, Zhong Yu wrote:
> We are probably discussing two very different types of programs that require
> different considerations:

There are *many* cases, some of which have more efficient solutions
than others. You are not likely to find too many simple slogans
beyond:

1. When possible, use design patterns that allow
java.util.concurrent (and/or other libraries/frameworks) to do
all the work for you in ensuring correctness and efficiency
without you dealing with it at all. (Simple examples include
Producer/Consumers and registries based on ConcurrentHashMaps.)

2. Otherwise, when possible, keep objects/data isolated within
threads/tasks.

3. Otherwise, when possible, stay within the bounds of simple
idioms including: final fields for immutable data; AtomicX's
(with compareAndSet) for reliably updatable single variables,
latches/phasers for barriers, etc.

4. Use locks (either library-based or builtin) for most
everything else.

There are and always will be cases that fall outside these.
Concurrent/parallel programming is at least as diverse as
any other aspect of programming, and just about any
style/approach can be made to work great, although some
with a lot more care and opportunity for error than others.

> On Wed, Aug 15, 2012 at 11:44 PM, Boehm, Hans<hans.boehm at hp.com>  wrote:

>> This doesn't mean that synchronization to avoid data races is entirely
>> free, but only that it's cost doesn't increase, and often decreases with
>> scale.  Doug may well have run more careful experiments around this.

Right; see above. It's hard to generalize beyond the observation
that, with sufficiently fine-grained control, sync is rarely the
main bottleneck, mainly because efficient combinations of immutability,
publication idioms, CAS, blocking sync, etc become available.
But that over-reliance on coarse-grained locking is a common
performance/scalability problem in Java programs.

-Doug


More information about the Concurrency-interest mailing list