Re: Locks and threads

[Linas Vepstas <linasvepstas@gmail.com>]

2009/2/11 Neil Jerram <neil@ossau.uklinux.net>:
> I've started working through the lock ordering and threading issues
> that we have.  My plan is (with 1.8.x)
>
> - first to address problems reported by helgrind (since I think we
>  should take advantage of external tools before adding debug code to
>  Guile internally)
>
> - then to run Linas's define-race program, and address the problems
>  that that shows up (including thread-safe define, hopefully)
>
> - then (or maybe as part of the previous step) to look again at
>  Linas's lock order debugging patch, to see if it would make sense to
>  apply some of that.
>
> Does that sound sensible; have I missed anything?

Err, sort of, yes, unless I misunderstand.  Guile 1.8 makes
a certain basic assumption that is splattered throughout
the code; it rather intentionally re-orders the order in which
one of the locks is taken.  If I remember correctly, its the
"in guile mode" lock.  So if you just go looking for locks
that are released out-of-order, you'll find lots of these.

At the time, I had decided that
1) it would be a lot of work to get these in order, and the
patch would likely be rejected, and
2) the reordering is essentially harmless (since its
consistently done).
3) there might have even been a performance hit (I don't
remember) by trying to get these into order.

This made using valgrind impossible, and that's why I created
the custom patch -- it made a point of ignoring this one
reversed-order, while checking for badness in everything else.

--linas