«

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.

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 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/wikipedi.../c/cf/Friz.jpg

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

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

On Apr 17, 9:31*am, cg_chas <cg_c...@hotmail.com> wrote:
> In multithreaded apps that require multiple synchronization primitives, if a
> resource must be locked and during that block you must lock yet again, then you
> must unlock in the reverse order that you locked.

I'm not sure this is correct. In fact, I'm pretty sure this is
incorrect. The unlock order is irrelevant. That can never lead to
deadlocks (at least not for what I would consider sane code). In sane
code, you can unlock in any order, and deadlocks will not arise.

Of course, you should be using stack destructors for unlocking in C++,
which will result in LIFO ordering.

On Apr 17, 4:35*pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> JoeSnodgrass<joe.s...@yahoo.com> wrote in news:23020668-d86c-489a-988b-
> 7b379f348...@j13g2000pro.googlegroups.com:
>
>
>
> > 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.

On Apr 18, 4:50*am, cg_chas <cg_c...@hotmail.com> wrote:
> On Sun, 17 Apr 2011 23:34:05 -0700 (PDT), Joshua Maurice
>
> <joshuamaur...@gmail.com> wrote:
> >On Apr 17, 9:31 am, cg_chas <cg_c...@hotmail.com> wrote:
> >> In multithreaded apps that require multiple synchronization primitives, if a
> >> resource must be locked and during that block you must lock yet again,then you
> >> must unlock in the reverse order that you locked.
>
> >I'm not sure this is correct. In fact, I'm pretty sure this is
> >incorrect. The unlock order is irrelevant. That can never lead to
> >deadlocks (at least not for what I would consider sane code). In sane
> >code, you can unlock in any order, and deadlocks will not arise.
>
> Then I refer you to the text again for a full description of what I apparently
> failed to convey. (Programming with POSIX Threads, pg 64)
>
> My description was not meant to be a complete description of a fixed locking
> hierarchy. A slightly better description seems to be in order though.
>
> Consider the list below to be a list of named resources that are shared
> througout an application. Also, the use of mutex below will be in the posix
> sense, not in a MS mutex sense. *The equivalent for MS would roughly bea
> critical section.
> A
> B
> C
> D
> E
>
> The developer's choice of locking order should consider knowing which shared
> resources must be synchronized during synchronizing other resources in the list.
> In other words, the efficiency of the fixed locking hierarchy. *The greater
> point is that there will be numerous cases of multiple synchronizations. *i.e.
> All code that needs both mutex_a and mutex_b must always lock mutex_a andthen
> mutex_b
>
> Lets say that one thread (thread #1) needed synchronized write access to B and
> D, and another thread (thread #2) needed synchronized write access to C and E.
> Other threads in the application require arbitrary synchronized write access to
> any and all of the other resources at other times.
>
> To avoid a deadlock, *thread #1 would (in order) lock B,C,D and thread #2 would
> (in order) lock C,D,E.
>
> To the statement you made, " I'm not sure this is correct. In fact, I'm pretty
> sure this is incorrect. The unlock order is irrelevant."
>
> I will defer to a direct quote so that the commonality between what I explained
> from memory and what the author (Butenhof is one "f" btw) coveys:
>
> "If the code invariants permit you to unlock mutex 1 safely at this point, you
> would do better to avoid owning both mutexes at the same time. *That is, unlock
> mutex 1, and then lock mutex 2. *If there is a broken invariant that requires
> mutex 1 to be owned, then mutex 1 cannot be released until the invariant is
> restored".
>
> Applying the same methodology to the above example implies a distinct unlock
> order. In the context of the quote, unlock order seems to matter.

I'm sorry that I don't follow that at all.

In fact, I think there might be some confusion. I completely agree
that a /lock/ order can prevent deadlock. A hierarchical locking
scheme is where everyone agrees that if they're going to acquire two
or more mutexes, then they should do so in a strict global ordering.

I disagree that the /unlocking/ side matters at all in such a scheme.
Do you have a concrete example where the "wrong" unlock order can lead
to a deadlock? (Note that I might be able to contrive a case where
"unlock order contributes to a deadlock", but that wouldn't be what I
was talking about.)

For example:
lock A
lock B
lock C
unlock B
lock B
With a hierarchical locking scheme can lead to a deadlock. It
specifically can result in deadlock because at the end it's trying to
acquire B while already holding C, and that is contrary to the
hierarchical locking rules we have established. However, consider the
following two examples:

Ex:
lock A
lock B
lock C
unlock C
unlock B
unlock A
Ex:
lock A
lock B
lock C
unlock B
unlock A
unlock C

The above two are functionally equivalent. There is no way that either
unlock order could contribute to a deadlock (at least not without
additional locking in this thread contrary to the hierarchical order).
Other threads don't care what order you unlock in. They cannot. If
they also follow the order rules, then they might just have to wait a
little longer depending on your unlock order, but there's no way that
unlock order can result in thread 1 owning A and trying to acquire B,
while thread 2 owning B and trying to acquire A. The only way for that
to happen is if one thread breaks the acquire order.

I am happy to discuss if I am wrong, and I would very much appreciate
an example proving me wrong.

And again, to repeat, as a matter of good C++ programming style, I
expect (nearly) all mutex acquisition and releasing to be done in
stack based lock objects, RAII, so in good code the order will be
LIFO, but it's not required to avoid deadlocks with a hierarchical
locking scheme.

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