Re: [PATCH] Final: thread lock nesting debugging

["Neil Jerram" <neiljerram@googlemail.com>]

2008/11/19 Neil Jerram <neiljerram@googlemail.com>:
> 2008/11/17 Linas Vepstas <linasvepstas@gmail.com>:
>> I've been seeing all sorts of deadlocks in guile, and so I wrote a small
>> debugging utility to try to track down the problems.
>
> Interesting patch!
>
> One query; I may be being a bit dumb, I'm only just recovering from a
> bad cold, but anyway...  Your patch checks for a thread unlocking
> mutexes in the reverse order that it locked them in (let's call this
> point "A").  But I thought your recent investigations had shown that
> the problem was threads doing locking in inconsistent order, e.g.
> thread 1 locks M1 and then M2, while thread 2 locks M2 and then M1
> (point "B").  Are points "A" and "B" equivalent?  (It isn't obvious to
> me if so.)

Also I wondered if there are already tools to debug this kind of thing
(without new Guile code), and a quick search finds this [1], which
suggests that helgrind could catch bad lock ordering for us.

[1] http://www.network-theory.co.uk/docs/valgrind/valgrind_113.html

      Neil