internal locks: new owner of contended lock must set waiters flag
authorRich Felker <dalias@aerifal.cx>
Tue, 24 Apr 2012 17:55:06 +0000 (13:55 -0400)
committerRich Felker <dalias@aerifal.cx>
Tue, 24 Apr 2012 17:55:06 +0000 (13:55 -0400)
commite7655ed37bc9c2d79d921af4f287ee5cf2788661
treeb21322ca5850ec44a9be633956a280f6786ab9de
parentf34d0ea511e552851c8c6148fb113816f41e6759
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