It's been bugging me for quite a few years, and I came to the conclusion
the only way to do it easily is with a language that makes it impossible
to write race conditions. If you know of one that isn't too esoteric,
I'd be interested. Otherwise, we're stuck with Java as the next best option.
On 20/08/[masked]:36, Ben Evans wrote:
> 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
> discussing it.
> ---------- 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
> 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<[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.
> Concurrency-interest mailing list
> [address removed]