条件变量的虚假唤醒(spurious wakeups)问题

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Leeds1993/article/details/52738845

引言

条件变量是我们常用的同步原语之一,它的正确使用方式一般如下图:

这里写图片描述

在wait端,我们必须把判断布尔条件和wait()放到while循环中,而不能用if语句,原因是可能会引起虚假唤醒。
那么,究竟什么是虚假唤醒,导致虚假唤醒的原因又是什么呢?

什么是虚假唤醒?

举个例子,我们现在有一个生产者-消费者队列和三个线程。

1) 1号线程从队列中获取了一个元素,此时队列变为空。

2) 2号线程也想从队列中获取一个元素,但此时队列为空,2号线程便只能进入阻塞(cond.wait()),等待队列非空。

3) 这时,3号线程将一个元素入队,并调用cond.notify()唤醒条件变量。

4) 处于等待状态的2号线程接收到3号线程的唤醒信号,便准备解除阻塞状态,执行接下来的任务(获取队列中的元素)。

5) 然而可能出现这样的情况:当2号线程准备获得队列的锁,去获取队列中的元素时,此时1号线程刚好执行完之前的元素操作,返回再去请求队列中的元素,1号线程便获得队列的锁,检查到队列非空,就获取到了3号线程刚刚入队的元素,然后释放队列锁。

6) 等到2号线程获得队列锁,判断发现队列仍为空,1号线程“偷走了”这个元素,所以对于2号线程而言,这次唤醒就是“虚假”的,它需要再次等待队列非空。

使用while()判断的原因

在多核处理器下,pthread_cond_signal可能会激活多于一个线程(阻塞在条件变量上的线程)。结果就是,当一个线程调用pthread_cond_signal()后,多个调用pthread_cond_wait()或pthread_cond_timedwait()的线程返回。这种效应就称为“虚假唤醒”。

Linux man page中也有提到:
虚假唤醒造成的后果:
这里写图片描述
需要对条件进行再判断以避免虚假唤醒:
这里写图片描述

如果用if判断,多个等待线程在满足if条件时都会被唤醒(虚假的),但实际上条件并不满足,生产者生产出来的消费品已经被第一个线程消费了。
这就是我们使用while去做判断而不是使用if的原因:因为等待在条件变量上的线程被唤醒有可能不是因为条件满足而是由于虚假唤醒。所以,我们需要对条件变量的状态进行不断检查直到其满足条件,不仅要在pthread_cond_wait前检查条件是否成立,在pthread_cond_wait之后也要检查。


参考资料:
http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups

--------------------- 作者:li27z 来源:CSDN 原文:https://blog.csdn.net/Leeds1993/article/details/52738845?utm_source=copy 版权声明:本文为博主原创文章,转载请附上博文链接!

posted @ 2018-10-10 12:15  (!物喜)&(!己悲)  阅读(8094)  评论(3编辑  收藏  举报