title: Deferred bcast wakeup for condition variables - is it valid?
body: <p>I'm implementing pthread condition variables (based on Linux futexes) and I have an idea for avoiding the "stampede effect" on <code>pthread_cond_broadcast</code> with process-shared condition variables. For non-process-shared cond vars, futex requeue operations are traditionally (i.e. by NPTL) used to requeue waiters from the cond var's futex to the mutex's futex without waking them up, but this is in general impossible for process-shared cond vars, because <code>pthread_cond_broadcast</code> might not have a valid pointer to the associated mutex. In a worst case scenario, the mutex might not even be mapped in its memory space.</p>
  
  <p>My idea for overcoming this issue is to have <code>pthread_cond_broadcast</code> only directly wake one waiter, and have that waiter perform the requeue operation when it wakes up, since it does have the needed pointer to the mutex.</p>
  
  <p>Naturally there are a lot of ugly race conditions to consider if I pursue this approach, but if they can be overcome, are there any other reasons such an implementation would be invalid or undesirable? One potential issue I can think of that might not be able to be overcome is the race where the waiter (a separate process) responsible for the requeue gets killed before it can act, but it might be possible to overcome even this by putting the condvar futex in the robust mutex list so that the kernel performs a wake on it when the process dies.</p>