From 3bec53e0d3bb5e74d2e2dca34f50aadfaf832607 Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Mon, 26 Sep 2011 13:14:41 -0400 Subject: 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. --- src/thread/pthread_cond_broadcast.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) (limited to 'src/thread/pthread_cond_broadcast.c') diff --git a/src/thread/pthread_cond_broadcast.c b/src/thread/pthread_cond_broadcast.c index 9c6a462b..848e288f 100644 --- a/src/thread/pthread_cond_broadcast.c +++ b/src/thread/pthread_cond_broadcast.c @@ -22,12 +22,8 @@ int pthread_cond_broadcast(pthread_cond_t *c) m = c->_c_mutex; /* Move waiter count to the mutex */ - for (;;) { - int w = c->_c_waiters2; - a_fetch_add(&m->_m_waiters, w); - if (a_cas(&c->_c_waiters2, w, 0) == w) break; - a_fetch_add(&m->_m_waiters, -w); - } + a_fetch_add(&m->_m_waiters, c->_c_waiters2); + c->_c_waiters2 = 0; /* Perform the futex requeue, waking one waiter unless we know * that the calling thread holds the mutex. */ -- cgit v1.2.1