C++11 并发编程系列(三)：条件变量(condition_variable) | 拾荒志

[murphypei]

https://murphypei.github.io/blog/2019/04/cpp-concurrent-3

并发编程作为 C++11 系列的一个重大更新部分，值得我们去探究，并应用其提升程序的性能。本系列参考了其他一些文章，对 C++11 并发编程的一些要点进行了总结，并给出一些示例。

[InnerCalmer]

您好，mutex lock 在wait()调用时阻塞了 是不是锁已经释放了？不然其他线程同一把锁 怎么进去notify呢。wait在收到notify后，又把锁关闭了，继续往下执行。有问题请指正。

[murphypei]

@InnerPeaceSwordsMan
您好，mutex lock 在wait()调用时阻塞了 是不是锁已经释放了？不然其他线程同一把锁 怎么进去notify呢。wait在收到notify后，又把锁关闭了，继续往下执行。有问题请指正。

我觉得不是的，cppreference 说的比较明确，wait 是 block current thread，此时应该是获取 mutex lock。你的问题我理解是这样的，notify 是系统实现的，内核是有权限 notify 的，并不需要 mutex lock，wait 持有 lock，并且收到了内核的 notify，释放 lock，继续执行。这个 notify 在 linux 可能是信号量实现的。mutex lock 只是针对用户线程。

[InnerCalmer]

@murphypei

@InnerPeaceSwordsMan
您好，mutex lock 在wait()调用时阻塞了 是不是锁已经释放了？不然其他线程同一把锁 怎么进去notify呢。wait在收到notify后，又把锁关闭了，继续往下执行。有问题请指正。

我觉得不是的，cppreference 说的比较明确，wait 是 block current thread，此时应该是获取 mutex lock。你的问题我理解是这样的，notify 是系统实现的，内核是有权限 notify 的，并不需要 mutex lock，wait 持有 lock，并且收到了内核的 notify，释放 lock，继续执行。这个 notify 在 linux 可能是信号量实现的。mutex lock 只是针对用户线程。

关键是同一把锁的其他线程无法跑到notify啊。

[murphypei]

@InnerPeaceSwordsMan

@murphypei

@InnerPeaceSwordsMan
您好，mutex lock 在wait()调用时阻塞了 是不是锁已经释放了？不然其他线程同一把锁 怎么进去notify呢。wait在收到notify后，又把锁关闭了，继续往下执行。有问题请指正。

我觉得不是的，cppreference 说的比较明确，wait 是 block current thread，此时应该是获取 mutex lock。你的问题我理解是这样的，notify 是系统实现的，内核是有权限 notify 的，并不需要 mutex lock，wait 持有 lock，并且收到了内核的 notify，释放 lock，继续执行。这个 notify 在 linux 可能是信号量实现的。mutex lock 只是针对用户线程。

关键是同一把锁的其他线程无法跑到notify啊。

你说的是对的，我之前记错了，重新看了一下，wait 会原子地释放 mutex，thread 被阻塞，被 notify 之后才会继续执行。是我的疏忽，非常感谢指正！

[jiachen1119]

说的很好，支持