std::condition_variable的wait谓词是否线程安全？原子化sharedBool是否合理？

原代码的线程安全性 #

不安全。如果sharedBool是普通bool类型，多线程环境下对它的读写没有同步机制，会触发C++标准定义的数据竞争（属于未定义行为）。哪怕用了wait(lock, ...)，谓词检查时虽然持有lock，但如果其他线程修改sharedBool时未持有同一把锁，当前线程的读取依然可能看不到最新值，甚至出现异常的内存操作结果。

将sharedBool改为std::atomic是否合理？ #

合理，但要遵守使用规范：

• std::atomic<bool>能保证读写操作的原子性，同时确保内存可见性——一个线程修改后，其他线程能立刻看到最新值，从根本上避免数据竞争。
• 别忘遵循condition_variable的核心规则：修改sharedBool的线程，完成修改后必须调用notify_one()或notify_all()；等待线程依然要通过带谓词的wait来等待条件满足，避免虚假唤醒。
• 当然，另一种常规方案是用普通bool配合互斥锁：所有对sharedBool的读写都必须在持有同一把锁的情况下进行，这也能保证线程安全，是condition_variable最常用的配套方式。

正确示例（atomic版） #

std::condition_variable var;
std::mutex mtx;
std::atomic<bool> sharedBool{false};

// 等待线程
std::unique_lock<std::mutex> lock(mtx);
var.wait(lock, [&] { return sharedBool.load(); });

// 修改线程
sharedBool.store(true);
var.notify_one();

正确示例（普通bool加锁版） #

std::condition_variable var;
std::mutex mtx;
bool sharedBool{false};

// 等待线程
std::unique_lock<std::mutex> lock(mtx);
var.wait(lock, [&] { return sharedBool; });

// 修改线程
std::lock_guard<std::mutex> lock(mtx);
sharedBool = true;
var.notify_one();

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