C++ std::atomic::wait 与 notify 实现高效无锁事件通知同步机制【详解】-C++-PHP中文网

std::atomic::wait不能替代condition_variable，仅适用于无锁状态通知；它仅在值严格匹配、平台支持原语且原子类型大小≤指针宽度时真正休眠，否则自旋；唤醒后必须重新检查条件，且不保护关联的非原子数据。

c++ std::atomic::wait 与 notify 实现高效无锁事件通知同步机制【详解】

std::atomic::wait 不能替代 condition_variable，它只适合做无锁状态通知，不是通用同步方案。

std::atomic::wait 什么时候真正休眠？

它只在三个条件同时成立时才调用底层 futex/WaitOnAddress 进入内核等待；否则退化为自旋。这三点是：

当前原子值严格等于传入的 expected 参数（按位比较，不是逻辑相等）
平台支持对应原语：Linux 需 futex，Windows 需 WaitOnAddress，macOS 当前仍回退到 mutex+condvar 模拟
原子类型大小 ≤ 指针宽度，且满足 std::is_trivially_copyable_v<t></t>（C++27 才放宽限制）

常见错误写法：counter.wait(0) —— 若 counter 是 64 位对齐但只存低 32 位，高位可能含垃圾值，导致永远不匹配。正确做法是先 load() 获取当前一致视图：int expected = counter.load(); counter.wait(expected);

notify_one 和 notify_all 的唤醒行为陷阱

它们不保证 FIFO 或“最早等待者优先”。notify_one 唤醒由内核调度器决定的任意一个线程；notify_all 唤醒所有当前阻塞在该原子变量上的线程，但这些线程被唤醒后必须重新检查状态——因为存在虚假唤醒（spurious wakeup）。

关键点在于：唤醒 ≠ 条件已满足。你必须在 wait() 返回后再次验证业务逻辑条件，例如：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

while (!data_ready.load(std::memory_order_acquire)) {
    data_ready.wait(false);
}
// 此时仍需确认结构体字段是否真正就绪，不能直接读

为什么不能用 atomic::wait 替代 condition_variable::wait？

根本差异在锁语义：std::atomic::wait 完全不接触任何互斥锁，它只观察那个原子变量本身；而 std::condition_variable::wait 必须绑定 std::unique_lock，并在内部自动解锁/重锁，保护的是整个临界区数据。

典型误用场景：

用 std::atomic<bool> ready</bool> 表示“结构体已初始化完毕”，写线程仅 ready.store(true, memory_order_release)，却未对结构体字段施加内存序约束
读线程 ready.wait(false) 返回后直接访问结构体字段，可能看到部分更新的脏数据

这不是原子变量本身的问题，而是它无法延伸保护其所代表状态背后的非原子数据。