wait morphing
2014-02-19 14:57
274 查看
解锁互斥量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)的顺序,否则发生异常!!。
参考网址:/article/7527842.html
(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)的顺序,否则发生异常!!。
参考网址:/article/7527842.html
相关文章推荐
- g_main_loop
- 使用QPainter 画饼图
- 刀片服务器和磁盘阵列卡(RAID)技术---永和维护
- 刀片服务器和磁盘阵列卡(RAID)技术---永和维护
- maven install Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-wa
- debian(wheezy) gvim GConf-WARNING **: Client failed to connect to the D-BUS daemon:
- uboot main_loop函数分析
- hdu——1022——Train Problem I
- plain类型tableview的footview不能跟随tableview下滑
- ORA-01555 "Snapshot too old" - Detailed Explanation (文档 ID 40689.1)
- A Turing-complete language: Brainf*ck
- Failed to fetch URL https://dl-ssl.google.com/android/repository/addons_list-2.xml
- 通过UltraISO来提取U盘启动盘的ISO镜像文件
- uva 154 rails
- git pull报错:Auto Merge Failed; Fix Conflicts and Then Commit the Result.
- 软RAID 0的技术概要及实现 v0.1b (正在修订之中)
- Bellman-ford算法的学习http://blog.csdn.net/niushuai666/article/details/6791765
- Bellman-ford算法的学习http://blog.csdn.net/niushuai666/article/details/6791765
- CEIO 2001 Chain
- 进程间通信、需要AIDL