addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrosseditemptyheartexportfacebookfolderfullheartglobegmailgoogleimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [ljc] Fwd: [concurrency-interest] Double Checked Locking in OpenJDK

From: Kevin W.
Sent on: Monday, August 20, 2012 1:13 PM
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]> 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.


Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy