Why does pthread_cond_wait have spurious wakeups?

by

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 pthread_call_signal or pthread_cond_broadcast on the condition occurred.
  • A thread blocked in pthread_cond_wait returns because of a call to pthread_cond_signal or pthread_cond_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.

More Related Contents:

  1. Pthreads in C. Simple example doesn’t work [closed]
  2. Undefined reference to pthread_create in Linux
  3. Why do pthreads’ condition variable functions require a mutex?
  4. Multiple arguments to function called by pthread_create()?
  5. Does guarding a variable with a pthread mutex guarantee it’s also not cached?
  6. Undefined reference to ‘pthread_create’ — linker command option order (libraries before/after object files?) [duplicate]
  7. Does pthread_cond_wait(&cond_t, &mutex); unlock and then lock the mutex?
  8. Kill Thread in Pthread Library
  9. How to set the name of a thread in Linux pthreads?
  10. Is it possible to determine the thread holding a mutex?
  11. pthread_create and passing an integer as the last argument
  12. Detached vs. Joinable POSIX threads
  13. Can I get Unix’s pthread.h to compile in Windows?
  14. How do I get a thread ID from an arbitrary pthread_t?
  15. Share condition variable & mutex between processes: does mutex have to locked before?
  16. Pass integer value through pthread_create
  17. When to use pthread_exit() and when to use pthread_join() in Linux?
  18. Check to see if a pthread mutex is locked or unlocked (After a thread has locked itself)
  19. Signal handling in pthreads
  20. Pthread Run a thread right after it’s creation
  21. How do you query a pthread to see if it is still running?
  22. When to use pthread condition variables?
  23. Does pthread_mutex_lock contains memory fence instruction? [duplicate]
  24. Implementing a FIFO mutex in pthreads
  25. Linux/POSIX equivalent for Win32’s CreateEvent, SetEvent, WaitForSingleObject
  26. Which thread handles the signal?
  27. Unexpected output in a multithreaded program
  28. PTHREAD_MUTEX_INITIALIZER vs pthread_mutex_init ( &mutex, param)
  29. Pthreads vs. OpenMP
  30. Program received signal SIGPIPE, Broken pipe

Leave a Comment