条件变量为什么要用互斥锁来保护？ - Linux环境编程 - ChinaUnix.net -
Powered by Discuz! Archiver
条件变量为什么要用互斥锁来保护？
如果pthread_cond_wait只有cond*一个参数，pthread_cond_signal也只有cond*一个参数，一个用来等，一个用来唤醒，工作的也挺好的不是么？
所有书所有资料所有人都说“互斥锁用来保护条件变量”“防止竞争”等等，为什么要保护？防止什么竞争？这个mutex的作用到底是什么？如果所有使用pthread_cond_wait的地方mutex参数各不相同，那么这个mutex参数是不是就相当于没有用了？
个人理解走到pthread_cond_wait后，如果条件不满足
该线程就休眠了，等待条件满足后被唤醒。节省了线程不断运行浪费的资源
回复 2# 赤夜萌香
& & 是啊是啊我的理解和你完全一样 但整个过程中和mutex有半毛钱关系么?? 晕死我了 ..
有关系，pthread_cond_wait内需要写入mutex变量参数
回复 4# 赤夜萌香
& & = =囧& &我就是想问设计者为什么要额外加这么一个mutex参数？如果不加会出什么问题？那些所谓“竞争”“保护”指的是什么？
& & 谢谢！
这个解释起来，就涉及mutex了，你会用互拆锁的话，后面的应该也不难。
pthread_cond_wait他除了判断条件是否满足，还有控制mutex的功能，
如果不满足条件，他要先释放互拆锁，在进入睡眠中
本帖最后由 赤夜萌香 于
18:46 编辑
也不能说让pthread_cond_wait判断条件，这个条件还是编译者自己给的，
如一个while循环，循环里的条件不满足了，就不做pthread_cond_wait
满足就执行pthread_cond_wait，执行pthread_cond_wait就会进入睡眠，但是会在睡眠前先释放他控制的互拆锁
回复 6# 赤夜萌香
& & 对，就是这里不明白。比如pthread_cond_wait (&COND , &MUTEX) ，那么这个函数只是简单地将三个类似 unlock(MUTEX), wait(COND), lock(MUTEX) 的函数原子地绑在一起而已么？如果是的话，那么这么做目的是什么？满足某个条件时也很有可能需要同时开始好多任务啊，为什么要强行lock掉呢？
本帖最后由 赤夜萌香 于
19:20 编辑
pthread_cond_wait,pthread_cond_signal
与pthread_mutex_lock,pthread_mutex_
是两部分，先有后者，后者使用上有不足处，故需要用前者来弥补。前者只是一个辅助弥补；
关键还是理解后者的用法，完全理解了，再去看前者是如何辅助lock与unlock的不足的；
如果还不能完全消化mutex部分就去看 cond会自然狠吃力，建议先完全理解mutex
回复 9# 赤夜萌香
& & 多谢！好像明白了 ..是不是因为mutex只有锁定与否，但继续运行的条件不只“mutex未锁”这么简单，所以用cond暂时阻塞并解锁以让出资源？
& & 如果是这样，那么如果我想实现一个简单得多的功能：当变量x为0时继续运行，此时mutex还有用么？直接写成 while (x) wait(&cond)就可以了是么？
& & .. 也就是说 .. 条件变量从一开始就不是我所想象的那个用途么　..
查看完整版本:　　最近在阅读《现代操作系统》，看到条件变量部分时非常疑惑条件变量为什么需要互斥锁，，查阅了一些资料，进行了一些思考。
　　我的疑惑点在于条件变量为什么需要有互斥锁的配合，我觉得原因有二。
　　第一点，首先我们要理解条件变量的作用是在等待某个条件达成时自身要进行睡眠或阻塞，避免忙等待带来的不必要消耗，所以条件变量的作用在于同步。条件变量这个变量其实本身不包含条件信息，条件的判断不在pthread_cond_wait函数功能中，而需要外面进行条件判断。这个条件通常是多个线程或进程的共享变量，这样就很清楚了，对于共享变量很可能产生竞争条件尤其还对共享变量加了条件限制，所以从这个角度看，必须对共享变量加上互斥锁。
　　第二点，pthread_cond_wait这个函数的过程我们必须了解，首先对互斥锁进行解锁（条件判断不属于函数的功能），解锁之后自身睡眠等待条件达成，注意这时候函数并未返回，因为还缺少一步，待条件完成后重新加锁。pthread_cond_wait提供的重要功能是保证这两个操作一定是原子操作不可分割。试想一下，如果进程A调用了pthread_cond_wait，先进行了解锁，这时候由于进程A时间片到期，轮换到进程B，进程B一直想要这把锁，现在终于拿到了，它干完了事情，调用pthread_cond_signal想唤醒A但是A并未完成睡眠等待条件达成，所以这个唤醒信号就丢失了。
　　其实第二点并不算是需要配合互斥锁的原因，而是因为有了互斥锁而提供的一个关键功能。但是从另一个角度看，条件变量和互斥锁的配合使非常紧密的。
　　还有一个值得思考的地方是，pthread_cond_wait函数最后一步要进行重新加锁，这时候就要求另一个线程将条件达成之时必须解锁。而pthread_cond_signal这个函数的流程是发送信号后本线程立刻阻塞，而等待条件的线程立刻被唤醒。这就可能造成一些问题。
这里另一个线程调用pthread_cond_signal有两种写法：
　　1、写在互斥锁操作之间：
pthread_mutex_lock
//其他语句
pthread_cond_signal
pthread_mutex_unlock
　　缺点：在某些线程的实现中，会造成等待线程从内核中唤醒（由于cond_signal)然后又回到内核空间（因为cond_wait返回后会发现锁并未解开的行为），所以一来一回会有性能的问题。但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 线程中，有两个队列，分别是cond_wait队列和mutex_lock队列， cond_signal只是让线程从cond_wait队列移到mutex_lock队列，而不用返回到用户空间，不会有性能的损耗。
所以在Linux中推荐使用这种模式。
　　2、写在互斥锁操作之后:
pthread_mutex_lock
//一些语句
pthread_mutex_unlock
pthread_cond_signal
　优点：不会出现之前说的那个潜在的性能损耗，因为在signal之前就已经释放锁了
　缺点：如果unlock之后signal之前，发生进程交换，另一个进程（不是等待条件的进程）拿到这把梦寐以求的锁后加锁操作，那么等最终切换到等待条件的线程时锁被别人拿去还没归还，只能继续等待。而这在上面的放中间的模式下是不会出现的。
参考文章：http://blog.chinaunix.net/uid--id-3282242.html
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：8221次
排名：千里之外
原创：12篇
(1)(3)(1)(1)(6)(2)(1)君，已阅读到文档的结尾了呢~~
linux系统下的多线程编程1深入,linux多线程编程,linux系统编程,linux系统编程 pdf,linux 多线程,linux多线程同步,linux c多线程,linux 多线程下载,linux多线程设计,linux 多线程编译
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
linux系统下的多线程编程1深入
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口}