[concurrency-interest] Joint Talk for JavaOne?

Dr Heinz M. Kabutz heinz at javaspecialists.eu
Thu Apr 5 15:52:23 EDT 2012


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
>


-- 
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


More information about the Concurrency-interest mailing list