[concurrency-interest] Double Checked Locking in OpenJDK

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

Left out another suggestion: instead of trying to scale via threads, can
scale via multiple instances of the app (applies to servers only, really).
This isn't as economical with jvm based apps as native ones, but may be an
option in some cases.

Sent from my phone
On Aug 14, 2012 7:09 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> 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/004a7ef2/attachment-0001.html>

More information about the Concurrency-interest mailing list