Take the 2-minute tour ×

To quote the man page:


So, pthread_cond_wait can return even if you haven't signaled it. At first glance at least, that seems pretty atrocious. It would be like a function which randomly returned the wrong value or randomly returned before it actually reached a proper return statement. It seems like a major bug. But the fact that they chose to document this in the man page rather than fix it would seem to indicate that there is a legitimate reason why pthread_cond_wait ends up waking up spuriously. Presumably, there's something intrinsic about how it works that makes it so that that can't be helped. The question is what.

Why does pthread_cond_wait return spuriously? Why can't it guarantee that it's only going to wake up when it's been properly signaled? Can anyone explain the reason for its spurious behavior?

share|improve this question
I'd imagine it has something to do with returning whenever the process catches a signal. Most *nixes don't restart a blocking call after a signal interrupts it; they just set/return an error code that says a signal occurred. –  cHao Dec 21 '11 at 18:34
@cHao: although note that because condition variables have other reasons for spurious wake-ups anyway, handling a signal isn't an error for pthread_cond_(timed)wait: "If a signal is delivered ... the thread resumes waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup". Other blocking functions indicate EINTR when interrupted by a signal (e.g. read), or are required to resume (e.g. pthread_mutex_lock). So if there were no other reasons for spurious wake-up, pthread_cond_wait could have been defined like either of those. –  Steve Jessop Dec 21 '11 at 19:09

3 Answers 3

up vote 24 down vote accepted

The following explanation is given by David R. Butenhof in "Programming with POSIX Threads" (p. 80):


In the following comp.programming.threads discussion, he expands on the thinking behind the design:

Patrick Doyle wrote: 
> In article , Tom Payne   wrote: 
> >Kaz Kylheku  wrote: 
> >: It is so because implementations can sometimes not avoid inserting 
> >: these spurious wakeups; it might be costly to prevent them. 

> >But why?  Why is this so difficult?  For example, are we talking about 
> >situations where a wait times out just as a signal arrives? 

> You know, I wonder if the designers of pthreads used logic like this: 
> users of condition variables have to check the condition on exit anyway, 
> so we will not be placing any additional burden on them if we allow 
> spurious wakeups; and since it is conceivable that allowing spurious 
> wakeups could make an implementation faster, it can only help if we 
> allow them. 

> They may not have had any particular implementation in mind. 

You're actually not far off at all, except you didn't push it far enough. 

The intent was to force correct/robust code by requiring predicate loops. This was 
driven by the provably correct academic contingent among the "core threadies" in 
the working group, though I don't think anyone really disagreed with the intent 
once they understood what it meant. 

We followed that intent with several levels of justification. The first was that 
"religiously" using a loop protects the application against its own imperfect 
coding practices. The second was that it wasn't difficult to abstractly imagine 
machines and implementation code that could exploit this requirement to improve 
the performance of average condition wait operations through optimizing the 
synchronization mechanisms. 
/------------------[ David.Buten...@compaq.com ]------------------\ 
| Compaq Computer Corporation              POSIX Thread Architect | 
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     | 
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/ 

share|improve this answer

There are at least two things 'spurious wakeup' could mean:

  • A thread blocked in pthread_cond_wait can return from the call even though no call to signal or broadcast on the condition occurred.
  • A thread blocked in pthread_cond_wait returns because of a call to signal or broadcast, however after reacquiring the mutex the underlying predicate is found to no longer be true.

But the latter case can occur even if the condition variable implementation does not allow the former case. Consider a producer consumer queue, and three threads.

  • Thread 1 has just dequeued an element and released the mutex, and the queue is now empty. The thread is doing whatever it does with the element it acquired on some CPU.
  • Thread 2 attempts to dequeue an element, but finds the queue to be empty when checked under the mutex, calls pthread_cond_wait, and blocks in the call awaiting signal/broadcast.
  • Thread 3 obtains the mutex, inserts a new element into the queue, notifies the condition variable, and releases the lock.
  • In response to the notification from thread 3, thread 2, which was waiting on the condition, is scheduled to run.
  • However before thread 2 manages to get on the CPU and grab the queue lock, thread 1 completes its current task, and returns to the queue for more work. It obtains the queue lock, checks the predicate, and finds that there is work in the queue. It proceeds to dequeue the item that thread 3 inserted, releases the lock, and does whatever it does with the item that thread 3 enqueued.
  • Thread 2 now gets on a CPU and obtains the lock, but when it checks the predicate, it finds that the queue is empty. Thread 1 'stole' the item, so the wakeup appears to be spurious. Thread 2 needs to wait on the condition again.

So since you already always need to check the predicate under a loop, it makes no difference if the underlying condition variables can have other sorts of spurious wakeups.

share|improve this answer
yes. Essentialy, this is what happens when an event is used instead of a synchronization mechanism with a count. Sadly, it appears that POSIX semaphores, (on Linux anyway), are subject to spurius wakeups as well. I just find it a bit strange that a fundamental functionality failure of synchronization primitives is just accepted as 'normal' and has to be worked around at user-level :( Presumably, developers would be up-in-arms if a system call was documented with a 'Spurious segfault' section or, perhaps 'Spurious connecting to the wrong URL' or 'Spurious opening of the wrong file'. –  Martin James Dec 22 '11 at 11:07
upvoted, Pretty clear. –  Alcott Jul 29 '12 at 13:22

Section "Multiple Awakenings by Condition Signal" in pthread_cond_signal has an example implementation of pthread_cond_wait and pthread_cond_signal which involves spurious wakekups.

share|improve this answer

Your Answer


