[concurrency-interest] Double Checked Locking in OpenJDK

Vitaly Davidovich vitalyd at gmail.com
Tue Aug 14 19:09:15 EDT 2012

Data race has a specific meaning in the context of the JMM; since the model
is defined (unlike, say, C++ prior to the latest standard), one should work
within it.

Your question seems to also ask about proper concurrency in general (e.g.
deadlock can happen due to lock ordering issues and not memory model
related issues).  I don't think there's a simple solution other than:

1) learn as much as possible about JMM and available concurrency constructs
in java
2) try to minimize shared state as a general principle
3) prefer immutable objects (in the "normal" sense, not the data racy stuff
discussed here)

I agree that shared state concurrency is hard (no other option in java at
the moment), but it gets really hard when one tries to "optimize" things by
adding data races.  So, trying to keep it simple and optimizing judiciously
is a good path, IMHO.

Again, luckily a memory model exists in java and behavior is well defined
when you don't try to be tricky, so it's mostly a function of learning the
platform tools and sticking to well-defined behavior.

P.S. I also think having a good mental model of how hardware/compiler works
is a great aid in letting make more sense in why things are done the way
they are rather than trying to simply memorize things.

Sent from my phone
On Aug 14, 2012 6:52 PM, "Raoul Duke" <raould at gmail.com> wrote:

> On Tue, Aug 14, 2012 at 3:36 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > I think the lesson should be avoid data races - period. :) if you find a
> > case where you can justify it (i.e. profiling/testing guided) then
> consider
> > it.  I bet there will be few and far in between cases like that.
> sincere, if vulgar, question: as a run-of-the-mill Joe Average
> programmer, how the heck do i even know that i've managed to avoid
> them? and if i do manage to avoid them, have i not just basically
> walked into potential, hiding, secret, waiting until after i ship to
> show up, deadlockville? (all in all, shared-mutable-state-concurrency
> seems pretty bad.)
> sincerely.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120814/856a6c87/attachment.html>

More information about the Concurrency-interest mailing list