注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

还东国的博客

行之苟有恒,久久自芬芳

 
 
 

日志

 
 

(转载)多线程编程中条件变量和虚假唤醒(spurious wakeup)的讨论  

2013-12-06 08:53:04|  分类: LINUX编程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

多线程编程中条件变量和虚假唤醒(spurious wakeup)的讨论 

http://siwind.iteye.com/blog/1469216

 

多线程 同步 互斥 条件等待 信号量 .

 

多线程编程中条件变量和虚假唤醒的讨论

 

1. 概述

条件变量(condition variable)是利用共享的变量进行线程之间同步的一种机制。典型的场景包括生产者-消费者模型,线程池实现等。

对条件变量的使用包括两个动作:

1) 线程等待某个条件, 条件为真则继续执行,条件为假则将自己挂起(避免busy wait,节省CPU资源)

2) 线程执行某些处理之后,条件成立;则通知等待该条件的线程继续执行。

3) 为了防止race-condition,条件变量总是和互斥锁变量mutex结合在一起使用。

一般的编程模式:

 

 

 

Java代码 复制代码 收藏代码

1.var mutex; 

2.var cond; 

3.var something; 

4. 

5.Thread1: (等待线程

6.lock(mutex); 

7.while( something not true ){ 

8.    condition_wait( cond, mutex); 

9.} 

10.do(something); 

11.unlock(mutex); 

12. 

13.============================ 

14. 

15.Thread2: (解锁线程

16. 

17.do(something); 

18..... 

19.something = true; 

20. 

21.unlock(mutex); 

22.condition_signal(cond); 

 

函数说明:

(1) Condition_wait():调用时当前线程立即进入睡眠状态,同时互斥变量mutex解锁(这两步操作是原子的,不可分割),以便其它线程能进入临界区修改变量。

(2) Condition_signal(): 线程调用此函数后,除了当前线程继续往下执行以外; 操作系统同时做如下动作:从condition_wait()中进入睡眠的线程中选一个线程唤醒, 同时被唤醒的线程试图锁(lock)住互斥量mutex, 当成功锁住后,线程就从condition_wait()中成功返回了。

 

2. 函数接口

 

1.pthread: pthread_cond_wait/pthread_cond_signal/pthread_cond_broadcast() 

2.Java: Condition.await()/Condition.signal()/Condition.signalAll() 


3. 虚假唤醒(spurious wakeup)在采用条件等待时,我们使用的是


1.while(条件不满足){ 

2.   condition_wait(cond, mutex); 

3.} 

4.而不是

5.If( 条件不满足 ){ 

6.   Condition_wait(cond,mutex); 

7.}  


这是因为可能会存在虚假唤醒”spurious wakeup”的情况。

也就是说,即使没有线程调用condition_signal, 原先调用condition_wait的函数也可能会返回。此时线程被唤醒了,但是条件并不满足,这个时候如果不对条件进行检查而往下执行,就可能会导致后续的处理出现错误。

虚假唤醒在linux的多处理器系统中/在程序接收到信号时可能回发生。在Windows系统和JAVA虚拟机上也存在。在系统设计时应该可以避免虚假唤醒,但是这会影响条件变量的执行效率,而既然通过while循环就能避免虚假唤醒造成的错误,因此程序的逻辑就变成了while循环的情况。

注意:即使是虚假唤醒的情况,线程也是在成功锁住mutex后才能从condition_wait()中返回。即使存在多个线程被虚假唤醒,但是也只能是一个线程一个线程的顺序执行,也即:lock(mutex)  ? 检查/处理 ? condition_wai()或者unlock(mutex)来解锁.

 

4. 解锁和等待转移(wait morphing)

 

解锁互斥量mutex和发出唤醒信号condition_signal是两个单独的操作,那么就存在一个顺序的问题。谁先随后可能会产生不同的结果。如下:

(1) 按照 unlock(mutex); condition_signal()顺序, 当等待的线程被唤醒时,因为mutex已经解锁,因此被唤醒的线程很容易就锁住了mutex然后从conditon_wait()中返回了。

(2) 按照 condition_signal(); unlock(mutext)顺序,当等待线程被唤醒时,它试图锁住mutex,但是如果此时mutex还未解锁,则线程又进入睡眠,mutex成功解锁后,此线程在再次被唤醒并锁住mutex,从而从condition_wait()中返回。

 

可以看到,按照(2)的顺序,对等待线程可能会发生2次的上下文切换,严重影响性能。因此在后来的实现中,对(2)的情况,如果线程被唤醒但是不能锁住mutex,则线程被转移(morphing)到互斥量mutex的等待队列中,避免了上下文的切换造成的开销。 -- wait morphing

 

编程时,推荐采用(1)的顺序解锁和发唤醒信号。而Java编程只能按照(2)的顺序,否则发生异常!!

 

SUSv3http://en.wikipedia.org/wiki/Single_UNIX_Specification的规范中(pthread),指明了这两种顺序不管采用哪种,其实现效果都是一样的。

  评论这张
 
阅读(625)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017