What's the deal with deadlocks

Discussion in 'Java' started by Joe Snodgrass, Apr 17, 2011.

  1. The general concept is simple enough, but it seems to me that you'll
    need special tools to diagnose this specific problem. How do you get
    the debugger to look inside threads, see that they're hung, and find
    out where the problem is happening? Do the debuggers have some
    features that I haven't heard of? TIA.
    Joe Snodgrass, Apr 17, 2011
    #1
    1. Advertising

  2. Joe Snodgrass

    markspace Guest

    On 4/17/2011 9:15 AM, Joe Snodgrass wrote:
    >
    > The general concept is simple enough, but it seems to me that you'll
    > need special tools to diagnose this specific problem. How do you get
    > the debugger to look inside threads, see that they're hung, and find
    > out where the problem is happening? Do the debuggers have some
    > features that I haven't heard of? TIA.



    Probably. Goggle is your friend. Since you posted this to a Java
    newsgroup, I'll supply one answer on topic for that group:

    <http://netbeans.org/kb/docs/java/debug-deadlock-screencast.html>
    markspace, Apr 17, 2011
    #2
    1. Advertising

  3. Joe Snodgrass

    Lew Guest

    markspace wrote:
    > Joe Snodgrass wrote:
    >> The general concept is simple enough, but it seems to me that you'll
    >> need special tools to diagnose this specific problem. How do you get
    >> the debugger to look inside threads, see that they're hung, and find
    >> out where the problem is happening? Do the debuggers have some
    >> features that I haven't heard of? TIA.


    > Probably. Goggle is your friend. Since you posted this to a Java newsgroup,
    > I'll supply one answer on topic for that group:
    >
    > <http://netbeans.org/kb/docs/java/debug-deadlock-screencast.html>


    More generally, the major IDEs all have hte ability to debug specific threads.
    If you haven't heard of that feature, then yes. Have you considered reading
    the fine manuals for the different IDEs and their debuggers?

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
    Lew, Apr 17, 2011
    #3
  4. On 04/17/2011 06:15 PM, Joe Snodgrass wrote:
    >
    > The general concept is simple enough, but it seems to me that you'll
    > need special tools to diagnose this specific problem. How do you get
    > the debugger to look inside threads, see that they're hung, and find
    > out where the problem is happening? Do the debuggers have some
    > features that I haven't heard of? TIA.


    IIRC a simple thread dump to console will already show deadlocks.

    Kind regards

    robert
    Robert Klemme, Apr 17, 2011
    #4
  5. Joe Snodgrass

    Ian Collins Guest

    On 04/18/11 08:35 AM, Paavo Helde wrote:
    > Joe Snodgrass<> wrote in news:23020668-d86c-489a-988b-
    > :
    >
    >>
    >> The general concept is simple enough, but it seems to me that you'll
    >> need special tools to diagnose this specific problem. How do you get
    >> the debugger to look inside threads, see that they're hung, and find
    >> out where the problem is happening? Do the debuggers have some
    >> features that I haven't heard of? TIA.

    >
    > Debugging deadlocks is easier than e.g. race conditions, because when a
    > deadlock appears the program is effectively stopped at the point of the
    > error and one can easily attach the debugger and study the stack traces of
    > all the threads. All the debuggers I use support this. The only problem is
    > that if there are many threads running then finding the actual culprit may
    > become tedious. I am not sure if this can be automated by some tools
    > currently.
    >
    > For avoiding deadlocks in advance one can use valgrind+helgrind and fix all
    > inconsistent lock order diagnostics it spits out. This way one should be
    > able to get rid of all potential deadlock scenarios in all code paths
    > covered by the test run.


    There are also static deadlock analysis tools such as Sun Studio's LockLint.

    --
    Ian Collins
    Ian Collins, Apr 17, 2011
    #5
  6. Joe Snodgrass

    Roedy Green Guest

    On Sun, 17 Apr 2011 09:15:35 -0700 (PDT), Joe Snodgrass
    <> wrote, quoted or indirectly quoted someone who
    said :

    >
    >The general concept is simple enough, but it seems to me that you'll
    >need special tools to diagnose this specific problem. How do you get
    >the debugger to look inside threads, see that they're hung, and find
    >out where the problem is happening? Do the debuggers have some
    >features that I haven't heard of? TIA.


    The primary technique is to use library code even if somewhat awkward.
    That way you have an expert author, and many eyes looking for bugs. It
    is much harder to find bugs involving threads since they are not as
    deterministic as ordinary bugs. Even if you have single stepped every
    instruction through all possible branchings, there can still be bugs
    hiding.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    Doing what the user expects with respect to navigation is absurdly important for user satisfaction.
    ~ anonymous Google Android developer
    Roedy Green, Apr 17, 2011
    #6
  7. On Apr 17, 4:35 pm, Paavo Helde <> wrote:
    > JoeSnodgrass<> wrote in news:23020668-d86c-489a-988b-
    > :
    >
    >
    >
    > > The general concept is simple enough, but it seems to me that you'll
    > > need special tools to diagnose this specific problem.  How do you get
    > > the debugger to look inside threads, see that they're hung, and find
    > > out where the problem is happening?  Do the debuggers have some
    > > features that I haven't heard of?  TIA.

    >
    > Debugging deadlocks is easier than e.g. race conditions, because when a
    > deadlock appears the program is effectively stopped at the point of the
    > error and one can easily attach the debugger and study the stack traces of
    > all the threads. All the debuggers I use support this. The only problem is
    > that if there are many threads running then finding the actual culprit may
    > become tedious. I am not sure if this can be automated by some tools
    > currently.
    >
    > For avoiding deadlocks in advance one can use valgrind+helgrind and fix all
    > inconsistent lock order diagnostics it spits out. This way one should be
    > able to get rid of all potential deadlock scenarios in all code paths
    > covered by the test run.


    Here's how NASA handles race conditions.

    http://tinyurl.com/42p2t5f

    I searched Dr. Dobbs J, and got ten pages of matches.
    Joe Snodgrass, Apr 18, 2011
    #7
  8. Joe Snodgrass

    Lew Guest

    Joe Snodgrass wrote:
    > Here's how NASA handles race conditions.
    >
    > http://tinyurl.com/42p2t5f
    >
    > I searched Dr. Dobbs J, and got ten pages of matches.


    That link was worth ten times the expected maximum value for a Usenet link.

    Not least because it led to http://www.usingcsp.com/cspbook.pdf,
    /Communicating Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword
    by Edsger W. Dijkstra.

    --
    Lew
    "For a variety of reasons, this is a book eagerly awaited by all who knew it
    was in the making; to say that their patience has been rewarded would be an
    understatement."
    - Edsger W. Dijkstra, in the foreword to /Communicating Sequential Processes/,
    by C. A. R. "Tony" Hoare.
    Lew, Apr 18, 2011
    #8
  9. * Lew, on 18.04.2011 22:22:
    > Joe Snodgrass wrote:
    >> Here's how NASA handles race conditions.
    >>
    >> http://tinyurl.com/42p2t5f
    >>
    >> I searched Dr. Dobbs J, and got ten pages of matches.

    >
    > That link was worth ten times the expected maximum value for a Usenet link.
    >
    > Not least because it led to http://www.usingcsp.com/cspbook.pdf, /Communicating
    > Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
    > Dijkstra.


    I have that in hardcover.

    Some other interesting old books:

    Parallell Programming in ANSI Standard ADA - George W. Cherry
    Lucid, the Dataflow Language - William W. Wadge & Edward A. Ashcroft
    OCCAM Programming Manual - INMOS Limited

    OCCAM was sort of a language designed to express more or less directly Hoare's
    concepts.

    Hm, I don't have anything on Linda.


    Cheers & hth.,

    - Alf

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Apr 18, 2011
    #9
  10. Joe Snodgrass

    Ian Collins Guest

    On 04/19/11 08:32 AM, Alf P. Steinbach /Usenet wrote:
    > * Lew, on 18.04.2011 22:22:
    >> Joe Snodgrass wrote:
    >>> Here's how NASA handles race conditions.
    >>>
    >>> http://tinyurl.com/42p2t5f
    >>>
    >>> I searched Dr. Dobbs J, and got ten pages of matches.

    >>
    >> That link was worth ten times the expected maximum value for a Usenet link.
    >>
    >> Not least because it led to http://www.usingcsp.com/cspbook.pdf, /Communicating
    >> Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
    >> Dijkstra.

    >
    > I have that in hardcover.
    >
    > Some other interesting old books:
    >
    > Parallell Programming in ANSI Standard ADA - George W. Cherry
    > Lucid, the Dataflow Language - William W. Wadge& Edward A. Ashcroft
    > OCCAM Programming Manual - INMOS Limited
    >
    > OCCAM was sort of a language designed to express more or less directly Hoare's
    > concepts.


    Someone else who has used OCCAM in anger? Wow I thought I was the only
    one left!

    --
    Ian Collins
    Ian Collins, Apr 18, 2011
    #10
  11. * Ian Collins, on 18.04.2011 23:53:
    > On 04/19/11 08:32 AM, Alf P. Steinbach /Usenet wrote:
    >> * Lew, on 18.04.2011 22:22:
    >>> Joe Snodgrass wrote:
    >>>> Here's how NASA handles race conditions.
    >>>>
    >>>> http://tinyurl.com/42p2t5f
    >>>>
    >>>> I searched Dr. Dobbs J, and got ten pages of matches.
    >>>
    >>> That link was worth ten times the expected maximum value for a Usenet link.
    >>>
    >>> Not least because it led to http://www.usingcsp.com/cspbook.pdf, /Communicating
    >>> Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
    >>> Dijkstra.

    >>
    >> I have that in hardcover.
    >>
    >> Some other interesting old books:
    >>
    >> Parallell Programming in ANSI Standard ADA - George W. Cherry
    >> Lucid, the Dataflow Language - William W. Wadge& Edward A. Ashcroft
    >> OCCAM Programming Manual - INMOS Limited
    >>
    >> OCCAM was sort of a language designed to express more or less directly Hoare's
    >> concepts.

    >
    > Someone else who has used OCCAM in anger? Wow I thought I was the only one left!


    You may well be the last: I never used it, I just wanted to learn about it
    (within my economic means, and I think I got that manual at a "basement bargain"
    shop).

    Anyway, this is fun.

    Discussing OCCAM, cross-posted to [comp.lang.c++] and
    [comp.lang.java.programmer]. :)


    Cheers,

    - Alf

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Apr 19, 2011
    #11
  12. Joe Snodgrass

    Tom Anderson Guest

    On Mon, 18 Apr 2011, Lew wrote:

    > Joe Snodgrass wrote:
    >> Here's how NASA handles race conditions.
    >>
    >> http://tinyurl.com/42p2t5f
    >>
    >> I searched Dr. Dobbs J, and got ten pages of matches.

    >
    > That link was worth ten times the expected maximum value for a Usenet link.
    >
    > Not least because it led to http://www.usingcsp.com/cspbook.pdf,
    > /Communicating Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword
    > by Edsger W. Dijkstra.


    If you like Dijkstra - and really, who doesn't - you might enjoy dipping
    into the archive of his papers:

    http://www.cs.utexas.edu/users/EWD/

    There's some heavily obscure stuff in there, but also dry wit, rigorous
    thinking, and interesting ideas.

    tom

    --
    A playwright is not the best person to talk about his own work for
    the simple reason that he is often unaware of what he has written. --
    Alan Bennett
    Tom Anderson, Apr 19, 2011
    #12
  13. Joe Snodgrass

    Noah Roberts Guest

    On 2011-04-17 09:15, Joe Snodgrass wrote:
    >
    > The general concept is simple enough, but it seems to me that you'll
    > need special tools to diagnose this specific problem. How do you get
    > the debugger to look inside threads, see that they're hung, and find
    > out where the problem is happening? Do the debuggers have some
    > features that I haven't heard of? TIA.


    I myself have always wondered how they could stand the smell.

    It's GOT to itch like a mother too.

    --
    http://crazycpp.wordpress.com
    Noah Roberts, Apr 19, 2011
    #13
  14. On Apr 18, 5:53 pm, Ian Collins <> wrote:
    > On 04/19/11 08:32 AM, Alf P. Steinbach /Usenet wrote:
    >
    >
    >
    > > * Lew, on 18.04.2011 22:22:
    > >>JoeSnodgrasswrote:
    > >>> Here's how NASA handles race conditions.

    >
    > >>>http://tinyurl.com/42p2t5f

    >
    > >>> I searched Dr. Dobbs J, and got ten pages of matches.

    >
    > >> That link was worth ten times the expected maximum value for a Usenet link.

    >
    > >> Not least because it led tohttp://www.usingcsp.com/cspbook.pdf, /Communicating
    > >> Sequential Processes/, by C. A. R. "Tony" Hoare, with foreword by Edsger W.
    > >> Dijkstra.

    >
    > > I have that in hardcover.

    >
    > > Some other interesting old books:

    >
    > >     Parallell Programming in ANSI Standard ADA  - George W. Cherry
    > >     Lucid, the Dataflow Language - William W. Wadge&  Edward A. Ashcroft
    > >     OCCAM Programming Manual - INMOS Limited

    >
    > > OCCAM was sort of a language designed to express more or less directly Hoare's
    > > concepts.

    >
    > Someone else who has used OCCAM in anger?  Wow I thought I was the only
    > one left!


    Ok, so tell me if this is how it works.

    You got a concurrent programming project, let's say in C++, and you're
    climbing the walls, because the results are unpredictable, the
    debugger shows nothing and the code looks fine.

    You say to yourself "It's gotta be a race condition, right? I mean
    I've tried everything else, and the behavior is consistent with that."

    The solution is to push C++ onto the back burner, whip out your credit
    card and buy a copy of Occam (or Linda, or whatever the kids are using
    these days.)

    Your job now becomes to interface Occam into your existing C++ code
    and use the Occam features to find and fix the race condition. Then
    you go back to C++ and work on whatever the boss says he wants done
    next.

    But the key is to give up all hope of ever fixing the race condition
    WITHOUT a language like Occam, because if you don't buy Occam, you're
    gonna be twisting in the wind until you're so far behind schedule that
    the boss fires you.

    Am I correct that my description is a highly reliable portrayal of how
    these situations develop?
    Joe Snodgrass, Apr 19, 2011
    #14
  15. Joe Snodgrass

    Lew Guest

    Joe Snodgrass wrote:
    > Ok, so tell me if this is how it works.


    I'm going to respond to your /reductio ad absurdum/ as though you were
    presenting a serious argument.

    > You got a concurrent programming project, let's say in C++, and you're
    > climbing the walls, because the results are unpredictable, the
    > debugger shows nothing and the code looks fine.


    The argument breaks down right here.

    The code *looks* fine is a function of how one looks, not of the code. Buying
    OCCAM or MAGICBOOJUM won't fix diddly, because the failure is in the Mark 1
    Eyeball and associated neural control and analysis circuits, not the software
    tools.

    "The debugger shows nothing" is useless because debuggers don't diagnose
    concurrency issues until they happen, and then only if you catch them in the
    right place. But hey, you throw enough shit at the wall and some of it will
    stick, right?

    "The results are unpredictable" only because one hasn't gathered enough
    information to make a prediction. The problem isn't in the results, once
    again. The failure is in the one gathering the information.

    So given the failure in the premises, any correctness in the conclusion will
    be pure coincidence.

    > You say to yourself "It's gotta be a race condition, right? I mean
    > I've tried everything else, and the behavior is consistent with that."


    Right, because incomplete information gathering combined with lame and
    ridiculously insufficient and misguided analysis should always be followed
    immediately by an baseless leap to an unfounded conclusion, followed by a rush
    to a randomly-chosen and utterly misunderstood ameliorative strategy.

    > The solution is to push C++ onto the back burner, whip out your credit
    > card and buy a copy of Occam (or Linda, or whatever the kids are using
    > these days.)
    >
    > Your job now becomes to interface Occam into your existing C++ code
    > and use the Occam features to find and fix the race condition. Then
    > you go back to C++ and work on whatever the boss says he wants done
    > next.
    >
    > But the key is to give up all hope of ever fixing the race condition
    > WITHOUT a language like Occam, because if you don't buy Occam, you're
    > gonna be twisting in the wind until you're so far behind schedule that
    > the boss fires you.
    >
    > Am I correct that my description is a highly reliable portrayal of how
    > these situations develop?


    No. At least, there's no evidence here that you are.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
    Lew, Apr 20, 2011
    #15
  16. On Apr 19, 11:01 pm, Lew <> wrote:
    > Joe Snodgrass wrote:
    > > Ok, so tell me if this is how it works.

    >
    > I'm going to respond to your /reductio ad absurdum/ as though you were
    > presenting a serious argument.
    >
    > > You got a concurrent programming project, let's say in C++, and you're
    > > climbing the walls, because the results are unpredictable, the
    > > debugger shows nothing and the code looks fine.

    >
    > The argument breaks down right here.
    >
    > The code *looks* fine is a function of how one looks, not of the code.  Buying
    > OCCAM or MAGICBOOJUM won't fix diddly, because the failure is in the Mark1
    > Eyeball and associated neural control and analysis circuits, not the software
    > tools.
    >
    > "The debugger shows nothing" is useless because debuggers don't diagnose
    > concurrency issues until they happen, and then only if you catch them in the
    > right place.  But hey, you throw enough shit at the wall and some of itwill
    > stick, right?
    >
    > "The results are unpredictable" only because one hasn't gathered enough
    > information to make a prediction.  The problem isn't in the results, once
    > again.  The failure is in the one gathering the information.
    >
    > So given the failure in the premises, any correctness in the conclusion will
    > be pure coincidence.
    >
    > > You say to yourself "It's gotta be a race condition, right?  I mean
    > > I've tried everything else, and the behavior is consistent with that."

    >
    > Right, because incomplete information gathering combined with lame and
    > ridiculously insufficient and misguided analysis should always be followed
    > immediately by an baseless leap to an unfounded conclusion, followed by arush
    > to a randomly-chosen and utterly misunderstood ameliorative strategy.
    >
    >
    >
    > > The solution is to push C++ onto the back burner, whip out your credit
    > > card and buy a copy of Occam (or Linda, or whatever the kids are using
    > > these days.)

    >
    > > Your job now becomes to interface Occam into your existing C++ code
    > > and use the Occam features to find and fix the race condition.  Then
    > > you go back to C++ and work on whatever the boss says he wants done
    > > next.

    >
    > > But the key is to give up all hope of ever fixing the race condition
    > > WITHOUT a language like Occam, because if you don't buy Occam, you're
    > > gonna be twisting in the wind until you're so far behind schedule that
    > > the boss fires you.

    >
    > > Am I correct that my description is a highly reliable portrayal of how
    > > these situations develop?

    >
    > No.  At least, there's no evidence here that you are.


    OK, so two of you have just contradicted me sarcastically, which means
    my post must have been wrong. In other words, there ARE ways to find
    and fix race conditions with without using a language like Occam.
    What are they, and where can I read up on them?
    Joe Snodgrass, Apr 21, 2011
    #16
  17. Joe Snodgrass

    Lew Guest

    Joe Snodgrass wrote:
    > OK, so two of you have just contradicted me sarcastically, which means
    > my post must have been wrong. In other words, there ARE ways to find
    > and fix race conditions with without using a language like Occam.
    > What are they, and where can I read up on them?


    Sarcasm for sarcasm - if you set it up, don't be too astonished to receive it
    back.

    But the points you raised, as ours, were valid and useful if one is trained to
    educe the point from Socratic discourse. I interpreted your post as a rather
    brilliant diatribe against the same sort of rush to judgment I attacked in my
    response, thus I believe us to be allies in championing an intelligent
    approach. That is why I introduced my post, "I'm going to respond to your
    /reductio ad absurdum/ as though you were presenting a serious argument." I
    feel quite sure you were pointing out exactly the sort of flawed reasoning I
    attacked in detail. Thus, you are providing the script for the young student,
    naively thinking Occam will save the day, and I the for the crotchety teacher
    attempting to impose a more engineering-oriented outlook.

    That said, the universe of discourse admits of a lot of room besides "Occam is
    our savior!" and "you can fix everything without Occam". I don't agree to
    frame the discussion in the terms you propose because the world is not limited
    to just the options you suggest. You asserted a conclusion that "there ARE
    [sic] ways" based on the sole premise (and fact) that Occam is not a magic
    bullet, without showing evidence or a chain of reasoning to link those
    statements.

    In fact, there ARE ways to find and fix race conditions, some with and some
    without Occam; they comprise a whole mess of practices and approaches and
    mindsets that are and likely always will be active topics of research and
    discussion among partisans.

    I shall forebear suggesting

    http://lmgtfy.com/?q=Java race condition detect and cure,

    choosing instead to follow that link myself and come up with dozens of useful
    leads that I read with pleasure.

    I shall not forebear suggesting:

    http://java.sun.com/docs/books/effective/
    http://www.javaconcurrencyinpractice.com/

    nor to scan through many of:
    http://www.ibm.com/search/csass/search/?q=Goetz&Search=Search

    Also, a scan upthread in this very discussion yields several answers to that
    very question. I commend to your attention in particular Dr. Patricia
    Shanahan's responses, which in a few short sentences lay the groundwork for
    everything you need to know. In one post, she recommends preventing the bugs,
    which is actually attainable by disciplined practice and thoughtful design.
    In the other, she limns the essentials of troubleshooting such matters.

    Your question is excellent, and seminal to the art of programming. If I may
    rephrase:

    How can one find, fix [and I'll add, prevent] race conditions, deadlocks, and
    other such parallel-execution foobars?

    Indeed, Grasshopper. Indeed.

    --
    Lew
    His barn burned down, and now he can see the moon.
    Lew, Apr 21, 2011
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Blackstone [MVP - Exchange]

    ASP.NET Deadlocks

    Martin Blackstone [MVP - Exchange], Aug 23, 2003, in forum: ASP .Net
    Replies:
    6
    Views:
    742
    Nick Wienholt
    Aug 24, 2003
  2. Mike Carr

    Deadlocks

    Mike Carr, Jul 16, 2004, in forum: ASP .Net
    Replies:
    9
    Views:
    622
    Mike Carr
    Jul 23, 2004
  3. Rogan Dawes

    Automatically detecting deadlocks?

    Rogan Dawes, May 5, 2004, in forum: Java
    Replies:
    2
    Views:
    408
    Rogan Dawes
    May 6, 2004
  4. rbt

    deal or no deal

    rbt, Dec 22, 2005, in forum: Python
    Replies:
    7
    Views:
    523
    Duncan Smith
    Dec 28, 2005
  5. Joe Snodgrass

    What's the deal with deadlocks

    Joe Snodgrass, Apr 17, 2011, in forum: C++
    Replies:
    17
    Views:
    578
Loading...

Share This Page