像这样假设pthread_cond_wait函数没有第二个参数，不也能实现同样的功能么。

iw1210

windoze 发表于 2013-01-17 18:09
回复 19# iw1210

Unix的一个设计原则就是，每个功能都要在保持完整的前提下尽量的小，也就是常说的高内聚低耦合。
以上面的mutex和cv为例，cv用来保存和检查状态，mutex用来做同步和并发控制，这两组功能是独立的，各自可用。


PS. 好吧，POSIX中cv不能离开mutex使用，但是理论上说其实也不是非这样不可，没有mutex的cv无非就是会有一些race condition罢了。

再致敬！！

windoze

回复 21# iw1210

另外，考虑到cv的典型使用方式：

1. 
   
2. pthread_mutex_lock(mtx)
   
3. while( cond_is_not_satisfied(...) ) {
   
4. pthread_cond_wait(cv, mtx);
   
5. }
   
6. actions_on_condition(...);
   
7. pthread_mutex_unlock(mtx);
   

复制代码

如果把mutex放在cv里面，API就没法保证cond_is_not_satisfied和actions_on_condition()在mutex被lock的状态下安全执行。
如果要保证这一点，API就得设计成这样：

1. 
   
2. pthread_cond_wait(cv, cond_check_callback, actions_on_condition_callback)
   

复制代码

其中cond_check_callback是用来检查条件的回调函数指针，actions_on_condition_callback是条件满足时要执行的函数指针。

API没有更简单，反而更复杂了。

shan_ghost

windoze 发表于 2013-01-17 18:09
回复 19# iw1210

Unix的一个设计原则就是，每个功能都要在保持完整的前提下尽量的小，也就是常说的高内聚低耦合。
以上面的mutex和cv为例，cv用来保存和检查状态，mutex用来做同步和并发控制，这两组功能是独立的，各自可用。

PS. 好吧，POSIX中cv不能离开mutex使用，但是理论上说其实也不是非这样不可，没有mutex的cv无非就是会有一些race condition罢了。

正交分解就基本摸到问题核心了。

想象一下实际问题。比如一个有GUI界面、有read_buf和write_buf的多线程程序，这程序你怎么写？


方案A：
定义GUI_mutex/read_buf_mutex/write_buf_mutex，分别保护这三个公共资源；需要访问涉及哪个资源的东西，就用哪个资源的mutex。

这个方案显然清晰明了，解决问题毫无压力。


方案B：
让cv（以及GUI上的每个元素、read/wrete_buf相关的cv等等）都自带mutex。

好吧，如果我需要先完成buf的更新、后改变cv，以允许其它等待者去读buf（否则就会出现脏读），用方案B该怎么做？一个一个锁它们自带的mutex吗？如果你锁了cv_read_buf_A、另一个线程锁了cv_read_buf_B呢？

shan_ghost

回复 22# windoze


    你这个例子比我的更清晰明了。

windoze

回复 23# shan_ghost


你说的这种情况其实需要3个cv，因为如果多个线程同时将同一个cv关联到不同的mutex是POSIX标准不允许的。
当然，这3个cv可以关联到同一个mutex，这就是目前POSIX API的灵活性所在。

iw1210

回复 23# shan_ghost

这种情况用三个 cv 不可以解决问题吗？

   

windoze

是啊，这就是我的意思。
cv用来保存状态，mutex用来同步

shan_ghost

iw1210 发表于 2013-01-17 18:38
回复 23# shan_ghost

这种情况用三个 cv 不可以解决问题吗？

我的意思本来就是用三个cv（甚至更多cv），注意我用了cv_read_buf_A和cv_read_buf_B——也就是在同一个资源上，也可能存在多个cv。但问题并不在这里。


因为mutex太分散（因为每个cv都带了自己的一份），所以当要修改其中一个资源时，就必须锁定与该资源相关的所有mutex，否则难以保证该资源的状态正常。而这个“锁定全部”的操作是非常容易出错的。

windoze

嗯，完全同意。
多个同步对象会导致同步的麻烦。
windows就是犯了这个错误，所以才需要WaitForMultipleObjects这个难看又难用的API

shan_ghost

windoze 发表于 2013-01-17 18:45
嗯，完全同意。
多个同步对象会导致同步的麻烦。
windows就是犯了这个错误，所以才需要WaitForMultipleOb ...

是的。

记得我以前曾说过，能“封装”的前提，是必须先完成正交分解，使得系统的各部分之间完全透明。

让cv自带mutex，初看很简单，很自动化，“封装”的很好；但实际上它违反了模块/接口正交化这个设计原则，导致一旦真拿来用，就是复杂度爆炸。

这可能是初学者最容易犯的错误了。