> lockdep would be right to moan about that -- if you have two tasks > trying to do that, they can deadlock against each other. There you go -- you are suffering the same weakness as lockdep. It's not possible for two tasks to deadlock when acquiring locks in a tree structure provided that the locks are always acquired going down a branch. (Or if the locks are always acquired going up a branch.) This sort of constraint could potentially be represented within lockdep, but right now there's no way to do it. > The real problem with lockdep is that mutexes have an owner and > semaphores simply don't. That isn't a problem with lockdep; it's a problem with trying to use lockdep to track general semaphore usage. Lack of explicit parents for semaphores hasn't prevented many semaphores from being converted to mutexes, complete with lockdep monitoring. My point was that even though a semaphore may be used for simple mutual exclusion in a way that should be compatible with replacement by a mutex, the replacement can't be carried out if the semaphore is being used to lock members of a tree.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds