From e7655ed37bc9c2d79d921af4f287ee5cf2788661 Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Tue, 24 Apr 2012 13:55:06 -0400 Subject: [PATCH] internal locks: new owner of contended lock must set waiters flag this bug probably would have gone unnoticed since it's only used in the fallback code for systems where priority-inheritance locking fails. unfortunately this approach results in one spurious wake syscall on the final unlock, when there are no waiters remaining. the alternative (possibly better) would be to use broadcast wakes instead of reflagging the waiter unconditionally, and let each waiter reflag itself; this saves one syscall at the expense of invoking the "thundering herd" effect (worse performance degredation) when there are many waiters. ideally we would be able to update all of our locks to use an array of two ints rather than a single int, and use a separate counter system like proper mutexes use; then we could avoid all spurious wake calls without resorting to broadcasts. however, it's not clear to me that priority inheritance futexes support this usage. the kernel sets the waiters flag for them (just like we're doing now) and i can't tell if it's safe to bypass the kernel when unlocking just because we know (from private data, the waiter count) that there are no waiters. this is something that could be explored in the future. --- src/thread/__lock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/thread/__lock.c b/src/thread/__lock.c index d1734096..5ba5dc5e 100644 --- a/src/thread/__lock.c +++ b/src/thread/__lock.c @@ -4,7 +4,7 @@ void __lock_2(volatile int *l) { if (!__syscall(SYS_futex, l, FUTEX_LOCK_PI, 0, 0)) return; - int old, tid = __pthread_self()->tid; + int old, tid = __pthread_self()->tid|INT_MIN; while ((old = a_cas(l, 0, tid))) { a_cas(l, old, old|INT_MIN); __syscall(SYS_futex, l, FUTEX_WAIT, old|INT_MIN, 0); -- GitLab