一名热爱体感技术的
业余专业开发人员

[转]条件变量的陷阱与思考

这个有点复杂,看了好久,大概了解了用法,转了备忘~~

http://originlee.com/2015/01/21/trick-in-conditon-variable/

1. 前言

在多线程编程中,互斥锁与条件变量恐怕是最常用也是最实用的线程同步原语。

关于条件变量一共也就pthread_cond_init、pthread_cond_destroy、pthread_cond_wait、pthread_cond_timedwait、pthread_cond_signal、pthread_cond_broadcast这么几个函数,但是在实际使用中却是很容易用错,后文将来分析几种常见使用情况的正确性。

2. 分析

下面是一个辅助基类、便于减少篇幅(为了简单起见,后文中的所有函数调用并未检查返回的错误情况):

2.1.1 版本一

错误,这种情况有可能丢失事件。当signal发生在wait之前,就会丢失这次signal事件。如下图


2.1.2 版本二

错误,同情况一一样有可能丢失事件。当signal事件发生在wait之前就会丢失signal事件。如下图

2.1.3 版本

错误。引入了bool变量来检查状态,但是遇到spurious wakeup仍然会发生错误。

什么是spurious wakeup?wikipedia中是这样说的:

spurious wakeup describes a complication in the use of condition variables as provided by certain multithreading apis such as posix threads and the windows api. even after a condition variable appears to have been signaled from a waiting thread’s point of view, the condition that was awaited may still be false. one of the reasons for this is a spurious wakeup; that is, a thread might be awoken from its waiting state even though no thread signaled the condition variable.

也就是说一次signal调用唤醒了2个或者2个以上的waiting中的线程,这种现象就是spurious wakeup,虚假唤醒。

apue上这样说:

posix规范为了简化实现,允许pthread_cond_signal在实现的时候可以唤醒不止一个线程。
在发生的spurious wakeup时候,waiting线程被意外的唤醒,然后到真正signal的时候,waiting线程在之前已经spurious wakeup唤醒了,这样就会造成不易debug的错误。如下图

2.1.4 版本四

正确。这个是推荐用法,apue, unp,man手册中都是这种用法,在wait上用while循环而不是if就可以正确处理spurious wakeup情况了。当发生spurious wakeup时,wait被意料之外的唤醒,但是循环条件并没有改变,于是循环继续执行pthread_cond_wait,然后继续进入wait,等待被正确的唤醒。

2.1.5 版本五

正确。版本五与版本四的唯一区别就是在唤醒的时候先解锁再调用signal发起唤醒。这么做不会有错误,但是可能有较大几率会使线程调度不在最理想状态,例如在wakeup调用中的解锁以后,调用signal以前,系统调度发生线程切换,使得signal没有在第一时间被发出。

这是在stackoverflow的一个帖子中的说法:http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex

Note that you can actually move the pthread_cond_signal() itself after the pthread_mutex_unlock(), but this can result in less optimal scheduling of threads, and you’ve necessarily locked the mutex already in this code path due to changing the condition itself.

2.1.6 版本六

正确,版本六与版本四的区别状态的改变和发起signal唤醒信号的顺序互换了,由于整个wakeup过程都在mutex的包含之下,所以并没有影响。但是个人更推荐版本四,因为更符合逻辑,不然apue和unp也不会都用版本四的写法顺序了:)

2.1.7 版本七