[concurrency-interest] Joint Talk for JavaOne?

Nathan Reynolds nathan.reynolds at oracle.com
Thu Apr 5 16:29:09 EDT 2012

I jumped at the first deadlock I found and stopped.  I didn't even 
consider that the AWT EventQueue thread had to be involved to deadlock 
the GUI.  I simply saw the deadlock and quit.  Nice distraction!  
Without spoiling it for others, it took me another minute to see the 
2^(n)^(d) deadlock.  Nice.  Please don't tell me that this is just 
another distraction from another deadlock hiding in the code.

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 4/5/2012 12:52 PM, Dr Heinz M. Kabutz wrote:
> You did not find the deadlock that caused your application to freeze
> up :-). 101 good Java developers now.
> On 05/04/2012, Nathan Reynolds<nathan.reynolds at oracle.com>  wrote:
>> I took the bait and tried out the demo on HotSpot 7 Update 3.  It didn't
>> deadlock for a minute or two.  Then the application froze.  I then used
>> jstack to dump the call stacks.  At the end of the report, it said
>> "Found one Java-level deadlock".  It then dumped out the locks and
>> threads involved in the deadlock.  I never looked at the source code...
>> in fact it wasn't in the zip file.  This took about 5-7 minutes from
>> starting the application to finding the deadlock in the call stacks.
>> A 100 good Java developers?  Really?  I guess I can understand.  Most
>> engineers don't understand locks.  Most of the time I get answers like
>> one should put a lock around shared variables.  This is accurate but
>> they can't really go any deeper.
>> It sounds like the material of your presentation should be very good.
>> It covers things that the deadlock detection tool probably can't figure out.
>> So, it seems like you have everything figured out.  Why do you need
>> someone else?
>> 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 4/5/2012 12:03 PM, Dr Heinz M. Kabutz wrote:
>>> Hi Nathan,
>>> a stack trace will only show you a certain class of obvious deadlocks
>>> that are easy to find and solve.  I remember solving deadlocks
>>> /before/ we had the brilliant deadlock detection tool in the
>>> ThreadMXBean.  Yes, the deadlock detection tool shows you /some/
>>> deadlocks, but definitely not all of them.  I can think of a bunch
>>> that it would not find:
>>> 1. Semaphores running out of permits
>>> 2. ReadWriteLocks trying to upgrade from write lock to read lock
>>> 3. Resource deadlocks
>>> And some others that I will not describe in detail, such as some nasty
>>> livelocks that we can cause which will hang up the JVM :-)
>>> I agree with Kirk - it should probably be a 3 hour workshop.  I've
>>> done this three times now - twice in Spain and once via webinar.  The
>>> workshop would involve some lessons on deadlocks, what causes them and
>>> how we can prevent them.  Also an explanation as to why we see them so
>>> seldom in real production.  I've got material prepared for this
>>> workshop.  And then a practical part to the workshop where they can
>>> try to find a deadlock in a body of code.
>>> Attached is an example of the workshop.  You can try find the deadlock
>>> if you like.  I've shown it to almost 100 good Java developers and so
>>> far, not one has found it by themselves.  I would expect that they
>>> should find it in 5 minutes.  In our workshop they would obviously be
>>> helped a bit with hints, so that they can walk away with a good
>>> experience.  Use anything you like.  Oscilloscope, jstack, jconsole,
>>> whatever you like.  Only rule for you guys on the
>>> "concurrency-interest" list is: you can only look at the code once
>>> you've found the problem, otherwise it would be too easy for you :-)
>>> Once you have found it, you can also fix the code and make sure that
>>> the code then works correctly.
>>> Regards
>>> Heinz
>>> --
>>> Dr Heinz M. Kabutz (PhD CompSci)
>>> Author of "The Java(tm) Specialists' Newsletter"
>>> Sun Java Champion
>>> IEEE Certified Software Development Professional
>>> http://www.javaspecialists.eu
>>> Tel: +30 69 75 595 262
>>> Skype: kabutz
>>> On 4/5/12 8:01 PM, Nathan Reynolds wrote:
>>>> I am curious as to the intended content of your presentation.  Here's
>>>> some ideas.  I wondering what you are planing on doing.
>>>>   1. Printing the call stacks with lock information using a tool such
>>>>      as jstack
>>>>   2. Press the "Detect Deadlock" button in JConsole
>>>>   3. Dealing with Lock and Condition objects instead of synchronized
>>>>      blocks
>>>>   4. Detecting live lock
>>>>   5. Distributed deadlocks
>>>> 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 4/5/2012 7:57 AM, Dr Heinz M. Kabutz wrote:
>>>>> Good afternoon,
>>>>> I am thinking of submitting a talk on finding and diagnosing
>>>>> deadlocks for JavaOne.  It might be a workshop, instead of a simple
>>>>> conference talk.  Or we might be able to turn the talk into a
>>>>> workshop where they need to find a deadlock in a body of code.
>>>>> Could be something different, which might go incredibly well or
>>>>> crash in a blaze of flames.  Would any of you be interested in
>>>>> co-presenting this with me at JavaOne?
>>>>> Regards
>>>>> Heinz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120405/a9aa92f9/attachment.html>

More information about the Concurrency-interest mailing list