<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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ⁿᵈ deadlock.  Nice.  Please don't tell me that
    this is just another distraction from another deadlock hiding in the
    code.<br>
    <br>
    <div class="moz-signature">
      <a
        href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds">Nathan
        Reynolds</a> | Consulting Member of Technical Staff |
      602.333.9091<br>
      <font color="red">Oracle</font> <a
        href="http://psr.us.oracle.com/">PSR Engineering</a> | Server
      Technology<br>
    </div>
    <br>
    On 4/5/2012 12:52 PM, Dr Heinz M. Kabutz wrote:
    <blockquote
cite="mid:CACLL95qwW96sz6pDwjqC5nXmB3D57P5vUWBN+xfBRnM3o6+J=g@mail.gmail.com"
      type="cite">
      <pre wrap="">You did not find the deadlock that caused your application to freeze
up :-). 101 good Java developers now.

On 05/04/2012, Nathan Reynolds <a class="moz-txt-link-rfc2396E" href="mailto:nathan.reynolds@oracle.com"><nathan.reynolds@oracle.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds"><http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds></a> |
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <a class="moz-txt-link-rfc2396E" href="http://psr.us.oracle.com/"><http://psr.us.oracle.com/></a> | Server Technology

On 4/5/2012 12:03 PM, Dr Heinz M. Kabutz wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">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
<a class="moz-txt-link-freetext" href="http://www.javaspecialists.eu">http://www.javaspecialists.eu</a>
Tel: +30 69 75 595 262
Skype: kabutz


On 4/5/12 8:01 PM, Nathan Reynolds wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds"><http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds></a> |
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <a class="moz-txt-link-rfc2396E" href="http://psr.us.oracle.com/"><http://psr.us.oracle.com/></a> | Server Technology

On 4/5/2012 7:57 AM, Dr Heinz M. Kabutz wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">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
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">
</pre>
      </blockquote>
      <pre wrap="">

</pre>
    </blockquote>
  </body>
</html>