On Fri, 2012-06-29 at 17:46 +0400, Alexander Potapenko wrote: > This may be not that easy to guess which locks are taken when the > deadlock has already occurred. > However a Valgrind-like tool is really an overkill for deadlock > detection: a small library that interposes pthread_mutex_* (or other > locking primitives) and keeps track of the locking order is fairly > enough.
helgrind has such a logic to detect an "inconsistent" lock ordering. However, just tracking the locking order to detect (potential) deadlock is not covering properly some cases. A.o., the "simple" lock ordering verification can give false positive when the application is using a guard lock. "try lock" is also not properly taken into account (e.g. if there are a mixture of try lock and lock operations on a set of locks). Properly covering these cases (i.e. not giving false positive with the guard lock, and not giving false negative for the try lock) seems not straightforward to me. Some algorithms have been developped to cover the guard lock case (search e.g. for "goodlock algorithm"). I have however not found anything which properly covers the "try lock" cases. Philippe ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
