[concurrency-interest] Double Checked Locking in OpenJDK

Nathan Reynolds nathan.reynolds at oracle.com
Tue Aug 14 19:37:28 EDT 2012


I would rather face having to untangle synchronized blocks than deal 
with race conditions.  Race conditions tend to be found in production 
systems or in load tests.  They are always very difficult to diagnose 
let alone repeat.  In fact, most engineers won't even bother with them 
if you can't reproduce it repeatedly.  I can deal with untangling 
synchronized blocks.  All of the information I need is in the code.  It 
might require a lot of time to get my head around the problem, though.  
In one case, we simply removed the contended synchronized block and 
everything worked just fine!

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 8/14/2012 4:19 PM, Vitaly Davidovich wrote:
>
> This is a general problem - can have a tangled mess of single threaded 
> code.
>
> Luckily, the jvm is a nice platform with good tooling for dealing with 
> threading issues, certainly better than a lot of others.
>
> Sent from my phone
>
> On Aug 14, 2012 7:13 PM, "√iktor Ҡlang" <viktor.klang at gmail.com 
> <mailto:viktor.klang at gmail.com>> wrote:
>
>
>
>     On Wed, Aug 15, 2012 at 12:59 AM, Nathan Reynolds
>     <nathan.reynolds at oracle.com <mailto:nathan.reynolds at oracle.com>>
>     wrote:
>
>         I would hope the average programmer would simply need to know
>         they should use synchronized blocks when accessing shared
>         state.  If the lock becomes contended, then the experts will
>         have to step in and figure out how to get rid of the lock and
>         deal with all of these issues.
>
>
>     Unfortunately the sad fact is that when you as an "expert" come
>     into a codebase loitered with synchronized statements, it's
>     completely demoralizing trying to untangle it since most people do
>     not know when or why to use them.
>
>     Cheers,
>>
>
>
>         Nathan Reynolds
>         <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>
>         | Consulting Member of Technical Staff | 602.333.9091
>         <tel:602.333.9091>
>         Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
>         Technology
>         On 8/14/2012 3:49 PM, Raoul Duke wrote:
>>         On Tue, Aug 14, 2012 at 3:36 PM, Vitaly Davidovich<vitalyd at gmail.com>  <mailto: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  <mailto:Concurrency-interest at cs.oswego.edu>
>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>         _______________________________________________
>         Concurrency-interest mailing list
>         Concurrency-interest at cs.oswego.edu
>         <mailto: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
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto: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/a201cbc8/attachment-0001.html>


More information about the Concurrency-interest mailing list