>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED] > >> Quick fix: the usual. Enable deadlock detection and if it >> returns deadlock, assume it is locked already and proceed (or >> do a recursive mutex, or a trylock). > >You have to be joking me ? geez. >...
This is way *more* common than you think--I've seen it around some big multithreaded OSS packages [can't remember which now]. >> Sure--and because most was for legacy reasons that adhered to >> POSIX strictly, it was very simple: we need POSIX this, that and >> that (PI, proper adherence to scheduler policy wake up/rt-behaviour, >> deadlock detection, etc). > >Some of this stuff sounds like recursive locking. Would this be a >better expression to solve the "top level API locking" problem >you're referring to ? Bingo. That's another way to "fix" it. Luckily, recursive locking can be safely and quickly done in user space (I own this lock, ergo I just inc the lock count). The problem with deadlocks is when the scenario gets more complex and you are trying to lock a mutex and the owner is waiting for a mutex whose owner is waiting for a mutex that you own...this more commonly happens when you don't know what the heck is going on in the code, which unfortunately is very common on people that inherits big pieces of stacks to maintain. >> Fortunately in those areas POSIX is not too gray; code to the book. >> Deal. > >I would think that there will have to be a graph discontinuity >between user/kernel spaces at kernel entry and exit for the deadlock >detector. Can't say about issues at fork time, but I would expect >that those objects would have to be destroyed when the process exits. fork time is not an issue, as POSIX makes forks and thread incompatible (in a nutshell, only the thread calling fork() survives, all the mutexes are [IIRC] reinitialized or something like that...). >The current RT (Ingo's) lock isn't recursive nor is the deadlock >detector the last time I looked. Do think that this is a problem >for legacy apps if it gets overload for being the userspace futex >as well ? (assuming I'm understanding all of this correctly) Should be not on the recursive side; as I said, that is easy to do [currently NPTL does it with the futexes]. The deadlock stuff gets hairier, but it's not such a big of a deal when you have your data structures setup. It takes time, though. >> Of course, selling it to the lkml is another story. > >I would think that pushing as much of this into userspace would >make the kernel hooks for it more acceptable. Don't know. Agreed. Deadlock checking though, has to be done in the kernel. For the generic case it is the only way to do it sanely. -- Inaky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
