Messages in this thread | | | Date | Thu, 10 Oct 2002 21:42:33 +0100 | From | Matthew Wilcox <> | Subject | RFC: No more deadlock detection for POSIX locks |
| |
The deadlock detection for posix locks really isn't worth anything any more. It was always slightly dubious, since a parent/child could remove each other's locks (thanks, POSIX!). But now it's really dubious since we store the TID, not the PID of the requesting process, and any thread can unlock a lock set by another thread.
Here's one situation in which it can falsely return -EDEADLK:
TID 1001, PID 1002 takes lock A TID 1003, PID 1004 takes lock B TID 1001, PID 1005 takes lock B, blocks TID 1003, PID 1004 takes lock A, gets -EDEADLK. Even though (1001,1002) isn't blocking on any lock and will release lock A in the future.
So how about we just delete the nasty deadlock detection code? I've never been fond of the user-triggerable O(N^2) algorithm, and we're permitted to not implement it (POSIX suggests applications set a timer to detect deadlock themselves, so anyone writing a portable application is already doing this).
Objections?
-- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |