Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Generally speaking, you can't.</strong></p> <p>Assuming the algorithm looks something like this:</p> <pre><code>ConditionVariable cv; void WorkerThread() { for (;;) { cv.wait(); DoWork(); } } void MainThread() { for (;;) { ScheduleWork(); cv.notify_all(); } } </code></pre> <p>NOTE: I intentionally omitted any reference to mutexes in this pseudo-code. For the purposes of this example, we'll suppose ConditionVariable does not require a mutex.</p> <p>The first time through MainTnread(), work is queued and then it notifies WorkerThread() that it should execute its work. At this point two things can happen:</p> <ol> <li>WorkerThread() completes DoWork() before MainThread() can complete ScheduleWork().</li> <li>MainThread() completes ScheduleWork() before WorkerThread() can complete DoWork().</li> </ol> <p>In case #1, WorkerThread() comes back around to sleep on the CV, and is awoken by the next cv.notify() and all is well.</p> <p>In case #2, MainThread() comes back around and notifies... <strong>nobody</strong> and continues on. Meanwhile WorkerThread() eventually comes back around in its loop and waits on the CV but it is now one or more iterations behind MainThread(). </p> <p>This is known as a "lost wakeup". It is similar to the notorious "spurious wakeup" in that the two threads now have different ideas about how many notify()s have taken place. If you are expecting the two threads to maintain synchrony (and usually you are), you need some sort of shared synchronization primitive to control it. This is where the mutex comes in. It helps avoid lost wakeups which, arguably, are a more serious problem than the spurious variety. Either way, the effects can be serious.</p> <p><strong>UPDATE:</strong> For further rationale behind this design, see this comment by one of the original POSIX authors: <a href="https://groups.google.com/d/msg/comp.programming.threads/cpJxTPu3acc/Hw3sbptsY4sJ" rel="nofollow">https://groups.google.com/d/msg/comp.programming.threads/cpJxTPu3acc/Hw3sbptsY4sJ</a></p> <blockquote> <p>Spurious wakeups are two things:</p> <ul> <li>Write your program carefully, and make sure it works even if you missed something.</li> <li>Support efficient SMP implementations</li> </ul> <p>There may be rare cases where an "absolutely, paranoiacally correct" implementation of condition wakeup, given simultaneous wait and signal/broadcast on different processors, would require additional synchronization that would slow down ALL condition variable operations while providing no benefit in 99.99999% of all calls. Is it worth the overhead? No way!</p> <p>But, really, that's an excuse because we wanted to force people to write safe code. (Yes, that's the truth.)</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload