[concurrency-interest] Double Checked Locking in OpenJDK
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
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
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
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.
More information about the Concurrency-interest