Problem is... all the interesting stuff as been neatly asided as "(and/or other libraries/frameworks)"
Actors, dataflow, functional-reactive, async futures, etc, etc.
Even his own ForkJoinPool can't be classed under "allow java.util.concurrent to do all the work for you" unless you've updated to JDK7 across the board.
On 20 August[masked]:36, Ben Evans <[address removed]>
People always seem to be interested in hearing about concurrency.
This post from Doug Lea is an excellent summary of how to approach
concurrent programming, and I thought the group might be interested in
---------- Forwarded message ----------
From: Doug Lea <[address removed]>
Date: Thu, Aug 16, 2012 at 11:25 AM
Subject: Re: [concurrency-interest] Double Checked Locking in OpenJDK
To: [address removed]
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<[address removed]> 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.