1

I understand that pthread_cond_wait() is documented to get spurious wake ups and the caller must check for that condition and that the motivation for this is to allow implementations of pthread_cond_wait() to have better performance and to force the caller to create more robust code.

However, I have not seen anyone get specific about the performance opportunity that this affords though other than mention of race conditions that would be expensive to avoid.

Can someone please go into detail about what race conditions would arise in order to ensure there were no spurious wake ups and what hardware architectures would cause such scenarios to arise?

WilliamKF
  • 41,123
  • 68
  • 193
  • 295
  • It turns out the real motivation was apparently to force users to check the predicate in a loop - the possible performance benefits seem to have been somewhat secondary: http://stackoverflow.com/a/8594644/12711 However, here's a bug report that indicates that NPTL might be introducing a bug by attempting to *prevent* spurious wakeups: http://sourceware.org/bugzilla/show_bug.cgi?id=13165#c13 I present this only as a comment because I don't know whether or not the bug report is valid (races are complex things). – Michael Burr Apr 03 '12 at 20:06
  • I think it's the other way round. It's understandable that the predicate should be rechecked since the condvar has no state, (unlike semaphores, say). This check loop covers up any spurious wakeups that occur even when the condvar has not been signaled. – Martin James Apr 04 '12 at 10:55

1 Answers1

1

There is no guarantee that your thread will run immediately when signaled. It just be marked as "ready" and will run at the mercy of the system scheduler. Between this time it becomes schedulable and the time it is actually scheduled, another thread could have changed the underlying condition.

For example:

Thread A: Wait on condition variable.

Thread B: Update state. Signal condition variable.

Thread C: Reset state

Thread A: Wake. Check underlying state, it is unchanged.

Michael
  • 54,279
  • 5
  • 125
  • 144
  • This is not a spurious wakeup - the condvar has been signaled. From Wiki: 'One of these reasons is a spurious wakeup; that is, a thread might get woken up even though no thread signalled the condition.' This is, IMHO, another way of saying 'condvars on Unix/Linux do not work correctly and a fix has to be applied in user code. Luckily, this is covered up by the design of condvars which means that a looping check has to be applied anyway'. – Martin James Apr 04 '12 at 10:45