作者回复: 不会,所以我才说应该优先用 broadcast。
作者回复: 动这个L之前一定要三思,谨慎些,想想是不是会影响到程序。
作者回复: 总是需要用 for 的,因为你没法保证收到信号之后那个状态就一定是你想要的。
作者回复: 原理上是这样,但是实践中最好不要这样混用同一个锁。
作者回复: 先说第二点吧,真正的谁先谁后是在底层调度的。所以我们很难干涉。很可能你感觉是A先B后,到了实际调度的时候却是B先A后。另外,条件变量的行为规范就是如此。所以记住就好了。
关于第一个问题,我又看了一下示例代码。在 demo61.go中确实是为了演示用法的。因为那里只有单发单收,所以不会有问题。而在demo62.go中就全是基于互斥锁了,那里是单发多收的。你可以看一下文章中每一段对应的是哪一个源码文件。
作者回复: 你这样给我代码我没法判断啊。你都改了哪些地方?
作者回复: 我记得在书里也说过类似的内容:条件变量常用于对共享资源的状态变化的监控和响应(由此可以实现状态机),同时也比较适合帮助多个线程协作操作同一个共享资源(这里的关键词是协作)。
条件变量有两种通知机制,这是互斥量没有的。互斥量只能保护共享资源(这里的关键词是保护),功能比较单一。所以条件变量在一些场景下会更高效。
你自己也说出了一些使用两个互斥锁来做的弊端。这些弊端其实就已经比较闹心了。一个是用两个锁对性能的影响,一个是两个锁如果配合不当就会造成局部的死锁。这还是多方协作操作同一个共享资源中最简单的情况。
再加上我前面说的那些,条件变量在此类场景下的优势已经非常明显了。注意它在Wait时还有原子级的操作呢。