[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Final: thread lock nesting debugging

From: Neil Jerram
Subject: Re: [PATCH] Final: thread lock nesting debugging
Date: Wed, 19 Nov 2008 23:21:53 +0000

2008/11/19 Neil Jerram <address@hidden>:
> 2008/11/17 Linas Vepstas <address@hidden>:
>> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]