计算机原理—条件变量为什么会有假唤醒
一、条件变量
在多线程的实际开发中，经常会用到条件变量。而使用条件变量时，比如标准库或Posix中的Conditional都会使用类似下面的代码来实现：
while(!pred())wait(lock);很多开发者特别是初学者，往往不明白为什么要增加一个while循环处理。后面用得多了接触广了，也只是听说可能是因为系统底层会出现信号误发射导致的条件变量的假唤醒。但一般大多数开发者也到此不再追根究底了。但为什么系统会误发信号呢？
二、假唤醒
spurious wakeup，假唤醒。很好理解，没想唤醒可却唤醒了，即这种唤醒不是开发者设计的或希望的（这和前面的伪共享有点类似）。条件变量监控的就是触发的信号，而这个信号是无论是谁触发，都需要经过系统的中转。而系统如果未经触发或别的信号的触发却进行了中转发射，就会产生假唤醒。
当然，还有其它的情况的假唤醒，比如多线程竞态导致的线程间竞争引入的假唤醒等。所以下面将对假唤醒的底层机制进行分析和说明。
三、原因
假唤醒的原因有很多种情况，一般主要的来说，分为系统层级和应用层级两种原因。下面将分别进行说明，重点分析说明一下系统层次的应用。
A.应用层级
应用层级的产生原因，主要在于多个线程等待时，如果捕获信号的机制有问题会导致错误的触发本应该无法被触发的线程，从而产生假唤醒。但这种问题，更多的是逻辑处理问题，并不是假唤醒的根本原因（理论上惊群也算）。
B.系统层次
系统层的主要原因也分为几类：
- 真实唤醒
这种真实唤醒是基于底层的信号真正发射导致的正常唤醒，但因为条件变量内部的安全机制导致被唤醒的线程无法进行工作，这有点类似于“惊群”。这也是条件变量内部实现的问题，它是正常的。 - 多核和多CPU的竞态
在这种情况下，signal发出信号导致多个线程被唤醒，这和原因1中的内容有呼应的意思 - 信号中断
在前面分析过，条件变量一般是基于futex等系统调用，如果收到信号（如SIGINT），阻塞的系统调用可能被中断返回EINTR，而wait内部机制都会处理这个EINTR，导致线程的假唤醒。 - 内核调度
在多核处理器上，现代操作系统存在着多线程调度、指令重排序或缓存一致性协议等复杂的应用，在某些特殊的场景下也可能导致假唤醒。另外，调度器的策略也有可能在某些情况下为避免死锁等情况唤醒一些低优先级的线程
四、假唤醒的应对
假唤醒的处理其实从根本上解决并不难，但为什么要丢给上层的开发者呢？说白了就是成本。底层如果使用更大粒度的锁就会解决这个问题，但导致的结果就是性能的急剧下降。投入和产出严重不成正比。所以在上层应用的标准（如POSIX等）都允许假唤醒的存在。既然交给了应用者，怎么解决这个问题呢？有两种方法，基本类似：
- while循环机制
这种方法与开头的方式一样：//使用 while+bool变量进行std::unique_lock<std::mutex>lock(mtx);while(!condition){cv.wait(lock);} - 引入wait中的谓词
std::unique_lock<std::mutex>lock(mtx);// 使用谓词来避免虚假唤醒cv.wait(lock,[]{returnready;});
注意，上面的两种情况是等价的。即虽然谓词情况下没有循环，但实际实现了类似的功能。
五、总结
对问题追根究底，从技术层面一定是好事。但在工程项目中就要从整体考虑了，不能因噎废食。但总体的原则还是要把握，不能学“上大人孔乙己”的四种“茴”字的写法那种学习方式。