[concurrency-interest] Double Checked Locking in OpenJDK

√iktor Ҡlang viktor.klang at gmail.com
Tue Aug 14 19:24:10 EDT 2012


On Wed, Aug 15, 2012 at 1:15 AM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> 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.
>
There are actually some nice higher-level abstractions for
concurrency/parallelism on the jvm...

Cheers,
√



> 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
>>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120815/e8ff3b1a/attachment.html>


More information about the Concurrency-interest mailing list