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.

1 files changed, 2 insertions, 6 deletions

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. */