使用atomic<bool>未加锁设置条件变量监控标志是否合法？

以下代码试图用条件变量和监控标志同步主线程与thread2，确保输出顺序符合预期：

int main() {
    std::mutex m;
    std::condition_variable cv;
    std::atomic<bool> ready = false;
    std::thread thread2 = std::thread([&](){
        std::unique_lock<std::mutex> l(m);
        cv.wait(l, [&ready]{return ready.load();});
        std::cout << "Hello from thread2\n"; // 应在主线程输出之后打印
    });
    std::cout << "Hello from main thread\n"; // 希望最先打印
    ready = true; // 向原子bool赋值，未加锁是否可行？
    cv.notify_one();
    thread2.join();
    std::cout << "Goodbye from main thread\n";
} 

现有代码的设计思路 #

这段代码将ready声明为std::atomic<bool>，主要有两个目的：

• 避免对标志的读写产生数据竞争（虽然多数平台下无实际问题，但严格来说无保护的非原子读写属于未定义行为）；
• 防止主线程中主线程输出和设置ready为true的代码行发生重排序——原子变量默认的memory_order_seq_cst内存序，能确保当前线程中存储操作之前的所有操作，对执行该变量加载操作的线程可见。

目前代码对ready的修改和notify_one的调用都没有加锁，已知调用notify_one无需加锁反而效率更高（避免thread2被唤醒后因等待锁再次挂起），但核心疑问是：修改ready标志是否需要放在与读取操作相同的mutex锁范围内？还是仅用std::atomic<bool>就足够？

解答：仅用std::atomic<bool>就足够，无需额外加锁 #

1. 原子变量已保证内存可见性与无竞争
   ready = true是原子存储操作（默认memory_order_seq_cst），wait谓词中的ready.load()也是同内存序的原子加载操作。这种内存序保证了主线程中std::cout << "Hello from main thread\n";的操作，一定会在ready被设为true之前完成，且该操作的结果对thread2可见，完全满足我们需要的输出顺序要求。

2. 条件变量wait的逻辑适配原子谓词
   cv.wait(l, predicate)的逻辑是：先解锁mutex进入等待；被唤醒后重新加锁，再检查谓词。这里谓词里的ready.load()是原子操作，即使没有锁保护，也能正确读取到ready的最新值，不会出现数据竞争或不一致的情况。

3. 加锁反而可能降低效率
   如果给ready = true加锁，虽然不会破坏正确性，但会导致notify_one调用时锁还未释放——thread2被唤醒后需要等待主线程释放锁才能继续执行，反而可能被操作系统再次挂起，违背了我们追求的效率优化目标。

补充：如果ready标志需要和其他共享状态一起修改（比如同时修改另一个非原子变量），此时需要用锁保护整个临界区；但在这个仅用单个标志同步的简单场景中，原子变量完全能满足同步需求。

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