|author||Rich Felker <email@example.com>||2011-09-26 13:14:41 -0400|
|committer||Rich Felker <firstname.lastname@example.org>||2011-09-26 13:14:41 -0400|
another cond var fix: requeue count race condition
lock out new waiters during the broadcast. otherwise the wait count added to the mutex might be lower than the actual number of waiters moved, and wakeups may be lost. this issue could also be solved by temporarily setting the mutex waiter count higher than any possible real count, then relying on the kernel to tell us how many waiters were requeued, and updating the counts afterwards. however the logic is more complex, and i don't really trust the kernel. the solution here is also nice in that it replaces some atomic cas loops with simple non-atomic ops under lock.
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions