[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
Neil