为何C++条件变量需要外部锁？无谓词场景下的疑问

首先得明确：你写的cv.wait()不带参数是不符合C++标准的，编译器根本不会通过——condition_variable的wait()重载必须接受unique_lock<mutex>作为第一个参数，这不是可选的，是强制要求。

为什么必须要这个锁？核心不是为了配合谓词，而是彻底避免“丢失通知”的竞态条件，这是条件变量设计的底层逻辑：

• 假设允许无锁调用wait，会出现这种致命场景：
  1. 线程A检查flag为false，准备调用cv.wait()；
  2. 就在线程A调用wait的前一瞬间，线程B完成了sharedData的修改，把flag设为true，然后调用cv.notify_all()；
  3. 线程A此时才进入wait，但通知已经发过了，它会永远阻塞下去，这就是“丢失通知”的竞态。

而传入锁之后，检查条件和进入wait的过程是原子的：

• 线程A先锁住mutex，检查flag为false，然后调用cv.wait(lock)——wait会自动释放锁并进入等待；
• 线程B必须先获取到同一个mutex，才能修改sharedData和flag，然后notify；
• 线程A被唤醒时，会自动重新获取锁，然后再次检查flag（防虚假唤醒），确认条件满足后再继续执行。

至于为什么条件变量不内置自己的mutex？
因为条件变量的作用是同步共享数据的状态变化，而共享数据本身已经需要一个mutex来保护（比如你的sharedData用dataMutex）。如果条件变量内置独立的锁，就无法和保护共享数据的锁关联起来，会导致条件检查（比如flag）和共享数据的状态不一致，照样引发竞态。条件变量的设计就是要复用保护共享数据的锁，保证状态检查和等待的原子性。

再看你的代码问题：

1. 非法调用cv.wait()，不符合标准；
2. 就算忽略语法问题，while(!flag)和cv.wait()之间的竞态会导致通知丢失，线程可能永远阻塞；
3. 读取sharedData时再加锁，虽然能保证线程安全，但前面的条件检查和等待的竞态依然存在。

正确的写法应该是：

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <atomic>
#include <chrono>

using namespace std;

condition_variable cv;
mutex dataMutex;
string sharedData;
atomic<bool> flag = false;

void doTask(){
    unique_lock<mutex> lock(dataMutex);
    while(!flag){ // 虚假唤醒后重新检查条件
        cv.wait(lock); // wait自动释放/重新获取锁
    }
    cout << sharedData << endl; // 此时锁仍持有，直接读取安全
}

void createTask(){
    lock_guard<mutex> lock(dataMutex);
    sharedData = "abc";
    flag = true;
    cv.notify_all();
}

int main(){
    thread a(doTask);
    this_thread::sleep_for(chrono::seconds(5));
    thread b(createTask);
    
    a.join();
    b.join();
    return 0;
}

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