互斥锁解锁会隐式通知等待条件变量的线程吗？

假设有一个与互斥锁mtx_关联的条件变量cv_。线程t1当前持有与mtx_关联的unique_lock对象ul，其他线程正通过cv_.wait(unique_lock(mtx_), ...)进行等待。如果t1不显式调用cv_.notify_all()，而是调用mtx_.unlock()，是否会隐式通知等待cv_的线程？

测试代码如下：

void worker() {
    while (true) {
        unique_lock<mutex> ul(mtx_);
        cv_.wait(ul, [&]() {
           // 某个条件判断
           some condition
        });

        ul.unlock(); // 实际测试中，这里的解锁似乎触发了其他等待线程的唤醒

        // 执行一些独立操作
        doing somthing ...

        ul.lock();
        // 更新共享资源
        update shared resource
        ul.unlock();
        cv_.notify_all();
    }
}

实际测试发现，中间的ul.unlock()似乎会唤醒处于等待状态的其他线程。

• 核心结论：解锁互斥锁mtx_.unlock()绝对不会隐式触发条件变量cv_的通知，这是C++标准明确规定的行为，二者是完全独立的操作。
• 你看到“唤醒”的真实原因：
  调用cv_.wait(ul, pred)时，线程会先检查谓词pred：如果谓词为真，直接返回；如果为假，才会解锁互斥锁并进入阻塞等待。当你在t1中解锁ul后，其他等待的线程会竞争获取到互斥锁，然后重新检查谓词pred——如果此时谓词恰好满足（比如你的条件逻辑存在疏漏，没有和共享资源状态强绑定），线程就会继续执行，看起来像是被“唤醒”了，但这是线程主动检查条件的结果，和unlock没有任何通知关系。
• 代码里的潜在问题：从你的代码逻辑看，共享资源是在ul.lock()之后才更新的，那ul.unlock()时共享资源状态并没有变化，这说明你的谓词some condition可能存在逻辑错误——比如没有正确依赖共享资源的状态，导致其他线程获取锁后误判条件为真。
• 正确使用姿势：永远只通过cv_.notify_one()或cv_.notify_all()来主动唤醒等待线程，解锁互斥锁只是让其他线程有机会获取锁并检查条件，不能替代通知操作。

内容的提问来源于stack exchange，提问作者Yue Lyu