Posted Feb 8, 2013 23:17 UTC (Fri) by cmccabe (guest, #60281)
Parent article: User-space lockdep
Last year I created a lock dependency analyzer called Locksmith which provides the same kind of functionality. The immediate motivation was to help debug some C++ open source projects at my company, Cloudera.
I've been trying to get more people interested in it, but I have a day job and I don't have a ton of time to devote to this. Hopefully I'll get a chance to give a talk on it at a conference or two this year.
I admit I only skimmed this patch set, but from a first glance the differences are: they require an init() call, whereas my library does not, they're GPLv2 only, whereas my library is BSD.
Another tool that can be used to debug these kinds of problems is helgrind, from the awesome valgrind suite of tools. helgrind has some limitations, though: for example, the documentation urges you not to use condition variables because it doesn't support them. Also, helgrind runs your program rather slowly.
I think one thing that is important for a lot of projects is the ability to roll their own locks and have them be instrumented. For example, if you rolled your own locks with futexes or atomic instructions, you need some way to notify your lock debugging library of what you've done. (I received this request from one potential Locksmith user). Please correct me if I'm wrong, but it seems to me that it's going to be difficult to do that in your GPLv3/BSD/proprietary program if it means linking against GPLv2-only source like liblockdep.