std::atomic::wait不能替代condition_variable，因其仅支持精确值匹配、无谓词等待、无内置超时机制、不自动同步mutex，且易因竞态导致永久阻塞。
std::atomic::wait 为什么不能直接替代 condition_variable
因为 std::atomic::wait 只能等待一个原子变量的**精确值匹配**，它不支持谓词（predicate）、不提供超时等待的原生接口（C++20 起才有 wait 重载支持 std::chrono，但语义仍是“等值”而非“等条件成立”），也不隐式配合 mutex——你得自己确保等待前的读操作与通知前的写操作构成同步关系。常见误用是：在未加锁读取原子变量后直接 wait，结果错过唤醒。
典型错误模式：
std::atomic<bool> ready{false};
// 线程 A（等待方）
while (!ready.load()) { // ❌ 错：load 和 wait 之间存在竞态窗口
ready.wait(false); // 若此时线程 B 已 notify，这里会永久阻塞
}
// 线程 B（通知方）
ready.store(true);
ready.notify_one();
正确做法是：用 load(std::memory_order_acquire) + 循环检查 + wait 组合，且必须保证通知方使用至少 std::memory_order_release 存储。
notify_one 和 notify_all 的实际唤醒行为差异
notify_one 并不保证只唤醒一个线程——它只是“最多唤醒一个就绪线程”，但若多个线程恰好同时从 wait 返回（例如因虚假唤醒或内核调度），notify_one 无法阻止后续线程继续执行。而 notify_all 会尝试唤醒所有当前在该原子变量上等待的线程，但注意：它不保证唤醒顺序，也不保证所有被唤醒线程都能立刻拿到 CPU；部分线程可能刚被唤醒就又因条件不满足而重新进入 wait。
立即学习“C++免费学习笔记（深入）”；
关键点：
-
notify_one更轻量，适合“单生产者-单消费者”场景，但需配合循环检查确保状态真正就绪 -
notify_all必须用于“一对多”或“状态可被多次消费”的情况（如 barrier、广播信号），否则易引发惊群（thundering herd） - 调用
notify_*前无需持有任何锁，但必须确保其 store 操作与 wait 的 load 构成 happens-before（通常靠 memory_order 控制）
wait 的底层依赖和跨平台兼容性陷阱
std::atomic::wait 在 Linux 上依赖 futex，Windows 上依赖 WaitOnAddress，macOS（自 macOS 12+）依赖 os_unfair_lock 或 pthread_cond 隐式封装。这意味着：如果目标平台不支持对应系统原语（如旧版 Android NDK、某些嵌入式 libc++ 实现），wait/notify 可能退化为忙等（busy-wait）甚至编译失败。
实操建议：
- 构建时检查
__cpp_lib_atomic_wait宏是否定义（C++20 要求 ≥ 201907L） - 避免在实时性要求极高的中断上下文或信号处理函数中调用
wait——它可能被系统挂起 - 调试时若发现 wait 不响应，先确认通知方是否真的执行了
store+notify，再检查 memory_order 是否一致（比如等待方用relaxedload，通知方用relaxedstore，则同步失效）
一个最小可行的无锁事件通知模式
下面是一个真正可用的、避免虚假唤醒和竞态的事件通知结构：
struct event_flag {
std::atomic<bool> flag{false};
void notify() noexcept {
flag.store(true, std::memory_order_release);
flag.notify_all(); // 用 notify_all 避免漏唤醒
}
void wait() noexcept {
while (!flag.load(std::memory_order_acquire)) {
flag.wait(false, std::memory_order_relaxed);
}
}
bool try_wait() noexcept {
return flag.load(std::memory_order_acquire);
}
};
注意这个模式里没有锁、没有 condition_variable、也没有额外状态变量。但它要求使用者严格遵守：通知只能发一次（否则重复 notify 无意义），且等待方必须接受“通知后 flag 保持 true”的语义。若需重置，就得引入 CAS 或额外状态机——那就不算“纯 wait/notify”了。
最易被忽略的一点：wait 的第二个参数（期望值）必须与当前 load 结果一致，否则调用立即返回；很多初学者传错值导致“看似 wait 了，其实根本没阻塞”。
