Spurious wakeup
This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. (September 2020) |
In computing, a spurious wakeup occurs when a thread wakes up from waiting on a condition variable and finds that the condition is still unsatisfied. It is referred to as spurious because the thread has seemingly been awakened for no reason. Spurious wakeups usually happen because in between the time when the condition variable was signaled and when the awakened thread was finally able to run, another thread ran first and changed the condition again. In general, if multiple threads are awakened, the first one to run will find the condition satisfied, but the others may find the condition unsatisfied. In this way, there is a race condition between all the awakened threads. The first thread to run will win the race and find the condition satisfied, while the other threads will lose the race, and experience a spurious wakeup.[citation needed]
The problem of spurious wakeup can be exacerbated on multiprocessor systems. When several threads are waiting on a single condition variable, the system may decide to wake all threads up when it's signaled. The system treats every signal( )
to wake one thread as a broadcast( )
to wake all of them, thus breaking any possibly expected 1:1 relationship between signals and wakeup.[1] If ten threads are waiting, only one will win and the other nine will experience spurious wakeup.[citation needed]
To allow for implementation flexibility in dealing with error conditions and races inside the operating system, condition variables may also be allowed to return from a wait even if not signaled, though it is not clear how many implementations do that. In the Solaris implementation of condition variables, a spurious wakeup may occur without the condition being assigned if the process is signaled; the wait system call aborts and returns EINTR
.[2] The Linux p-thread implementation of condition variables guarantees that it will not do that.[3][4]
Because spurious wakeup can happen, when a thread wakes after waiting on a condition variable, it should always check that the condition it sought is still satisfied. If it is not, it should go back to sleeping on the condition variable, waiting for another opportunity.[5]
References
[edit]- ^ Raymond Chen (February 1, 2018). "Spurious wake-ups in Win32 condition variables". Retrieved May 9, 2020.
- ^ "Interrupted Waits on Condition Variables (Solaris Threads Only)". Oracle Corporation. Retrieved May 9, 2020.
- ^
"pthread_cond_wait(3) - Linux man page". die.net. Retrieved May 9, 2020.
These functions shall not return an error code of [EINTR].
- ^ "pthread_cond_timedwait, pthread_cond_wait - wait on a condition". The Open Group. 2018. Retrieved May 9, 2020.
- ^ Arpaci-Dusseau, Remzi; Arpaci-Dusseau, Andrea (November 2023). "Condition Variables" (PDF). Operating Systems: Three Easy Pieces.