c++oding="utf-8" ?>
std::atomic::wait 是基于 futex 的阻塞等待而非轮询，需严格满足三条件：类型支持、值严格相等、有对应 notify；错误轮询会导致死锁或性能崩溃，正确用法是忙等退避后传当前 load 值调用 wait。
std::atomic::wait 为什么不能直接用于轮询
它不是轮询替代品，而是基于 futex 的阻塞等待机制——调用 std::atomic::wait 会让线程进入内核休眠态，直到被 std::atomic::notify_one 或 std::atomic::notify_all 显式唤醒。强行“轮询式调用 wait”不仅没意义，还会因频繁系统调用拖垮性能，甚至触发内核拒绝（如 Linux 的 futex EAGAIN 限频）。
常见错误是写成：
while (flag.load() == false) {
flag.wait(false); // ❌ 错误：可能永远等不到 notify，且反复休眠/唤醒开销巨大
}
这既违背设计意图，又在无 notify 场景下导致死锁或饥饿。
std::atomic::wait 的正确使用前提
必须满足三个条件才能安全高效使用：
-
std::atomic类型需支持等待（C++20 起仅std::atomic<bool></bool>、std::atomic<integral></integral>和std::atomic<:shared_ptr></:shared_ptr>等少数类型有wait/notify成员） - 等待值必须与当前原子值**严格相等**，否则立即返回；不支持谓词或范围匹配
- 必须有另一个线程在合适时机调用
notify_one或notify_all—— 没 notify 就永远等下去
例如 std::atomic<int></int> 可以 wait(0)，但若当前值已是 1，则 wait(0) 立即返回；若值为 0 且无人 notify，线程挂起。
高性能等待的典型模式：wait + load 循环
真正兼顾低延迟和低开销的做法是“先忙等一小会儿，再退避进 wait”，避免过早陷入内核态。标准库不提供内置退避，需手动组合：
while (flag.load(std::memory_order_acquire) == false) {
// 忙等前几轮（比如 10–100 次），利用 CPU 缓存局部性
if (spin_count-- > 0) {
std::atomic_thread_fence(std::memory_order_acquire);
continue;
}
// 退避后才调用 wait，传入当前观察到的值（防 ABA）
flag.wait(false, std::memory_order_acquire);
}
关键点：
- 每次
wait都应传入flag.load()当前值（而非固定常量），防止其他线程在你调用wait前已改值又 notify，导致错过唤醒 -
std::memory_order_acquire在load和wait中保持一致，确保后续读操作能看到 notify 之前写的内存 - 忙等轮数不宜过大（通常 ≤ 100），否则浪费 CPU；也不宜为 0，否则失去缓存友好性
跨平台兼容性与编译器限制
std::atomic::wait 并非所有平台都真正高效：
- Linux（glibc ≥ 2.34 + kernel ≥ 5.1）用 futex WAIT/BASED_NOTIFY，延迟约 1–10 μs
- Windows MSVC 19.30+ 用 SRWLock + WaitOnAddress，效果接近
- macOS 目前（Clang 15 / libc++）仍回退到 mutex + condition_variable 模拟，
wait变成昂贵的用户态阻塞，慎用 - 某些嵌入式 STL（如 newlib、picolibc）干脆没实现
wait/notify，链接时报错undefined reference to __atomic_wait
建议在 CMake 中检查：if (__cpp_lib_atomic_wait >= 201907L)，并搭配运行时探测（如 try-catch + dlsym）避免崩溃。
真正难处理的是 notify 的时序——notify 发生在 wait 之前会导致丢失，所以生产代码里往往还得加一层状态双检或用 std::atomic_flag 配合自旋兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
