2

After answering to a different question, I decided to investigate the exact issue behind spurious wakes.

First and foremost: This is NO (!!!) dulicate of any question here. Most questions just ask how to properly handle spurious wakes, but none of them actually tries to break down HOW they happen.

We all know that a wait() on a condition_variable may cause a wake up, even though notify() is not called.

std::mutex cond_mutex;
std::condition_variable cv;

void test(){
    std::unique_lock<std::mutex> lk(cond_mutex);
    cv.wait(lk); // may wake up without notify()
}

I know how to properly wait(), but what I do not know is what exactly causes these spurious wakes.

Would be interesting if someone could shed some light on it, from a very low level perspective. It must be some kind of race condition, but I would like to understand exactly how / why it occurs.

Skriptkiddie
  • 411
  • 2
  • 7
  • 1
    This has nothing to do with C++. https://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups – llllllllll Dec 01 '18 at 07:36
  • 1
    So you are saying that it is not valid to actually understand how any of the features offered by C++ work just because they are using underlying POSIX stuff? I appreciate the link, btw, however, it does not reveal the myth imho. It just contains information that is "commonplace" anyway. – Skriptkiddie Dec 01 '18 at 07:44
  • 1
    I wonder if https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs is somehow related. – bipll Dec 01 '18 at 07:44
  • I think it has everything to do with C++. The "_using a loop protects the application against its own imperfect coding practices_" mindset is mind-boggling and I can't fathom how this kind of thinking was let into the standard. Now everyone has to write the same silly loop. – Ted Lyngmo Dec 01 '18 at 08:07
  • @Skriptkiddie Probably like this: 1. Allowing this behaviour makes some pthread implementations much more effective, and fixing it would prove too costly. 2. Thus this behaviour is explicitly allowed in pthread specification. 3. C++ Standard, while being a separate document, closely follows the pthread specification, to not reinvent the wheel. Fixing this particular point would make the two diverge notably. Letting it go as is does notably simplify typical implementations. – bipll Dec 01 '18 at 08:08
  • @TedLyngmo "silly loop"?? In most of the case, you're waiting for a specific condition, whether there is a `notify` from other threads is of secondary importance. Even if there is no spurious wakeup, most of time you still need to write that "silly loop" to check the condition at the entry and to verify no one has invalidated that condition before you get back the mutex. – llllllllll Dec 01 '18 at 08:36
  • The silly loop I'm referring to is the one just checking if the condition really has been met - before any meaningful processing can be done. The same thing done in Windows does not need that so it is possible to do without it. It just leaves room for mistakes. – Ted Lyngmo Dec 01 '18 at 11:51
  • 1
    It _does_ rather seem like an abstraction leak. I'd guess it comes more from "don't pay for what you don't use" - if someone doesn't want to bother "properly" handling spurious wakes, then they don't have to, and the system hasn't spent energy internally handling it for them. But that does seem a bit weak. And the notion of abstracting away OS- and hardware-stuff seems to be eroded with each passing version of the standard. :( – Lightness Races in Orbit Dec 02 '18 at 01:40

0 Answers0