std::atomic::wait不能用于轮询，因为它是阻塞式等待、依赖futex且必须配合notify使用；轮询应改用load+yield+指数退避组合。
std::atomic::wait 为什么不能直接用于轮询等待
它不是为轮询设计的——std::atomic::wait 是一个**阻塞式等待**，依赖操作系统 futex（Linux）或类似内核原语，必须配合 std::atomic::notify_one/notify_all 使用。你不能靠它“轮询”某个值变化，否则会立刻返回（因为没被通知），陷入空转，反而比普通 load 更重。
常见错误是写成这样：
while (flag.load() != true) {
flag.wait(false); // 错！flag 当前是 false，但没人 notify，永远阻塞或立即失败（取决于实现）
}
实际行为取决于平台和 libc++/libstdc++ 实现细节，但结果不可靠：可能死锁、忙等、或直接崩溃（如 libc++ 在未 notify 时调用 wait 可能 abort）。
真正适合轮询等待的替代方案：load + yield + 条件退避
如果你确实需要轮询（比如超时等待、避免线程挂起、或在实时上下文中），应该手动组合 load 和轻量级让出：
立即学习“C++免费学习笔记（深入）”；
-
std::atomic<t>::load()</t>用std::memory_order_acquire或更弱的序（如relaxed，若仅关心值不关心同步） - 每次 load 后调用
std::this_thread::yield()，提示调度器切换线程，降低 CPU 占用 - 加指数退避（如首次 0 次 yield，第二次 1 次，第三次 2 次…）防止密集空转
示例：
bool wait_for_flag(std::atomic<bool>& flag, int max_retries = 1000) {
for (int i = 0; i < max_retries; ++i) {
if (flag.load(std::memory_order_acquire)) return true;
if (i > 0) std::this_thread::yield();
// 可选：i < 10 ? yield() : std::this_thread::sleep_for(1us);
}
return false;
}
什么时候该用 std::atomic::wait 而不是轮询
只在满足以下全部条件时才用 std::atomic::wait：
- 目标平台支持（C++20，且 libc++ ≥ 14 / libstdc++ ≥ 12，Windows MSVC ≥ 19.30）
- 你控制变量的修改方，并能确保每次修改后调用
notify_one或notify_all - 等待方可以接受被内核挂起（即不介意线程调度延迟）
- 场景是“事件驱动”而非“状态轮询”，例如：生产者写完数据后 notify，消费者 wait 到数据就绪
典型正确用法：
std::atomic<bool> ready{false};
// 生产者
data = compute();
ready.store(true, std::memory_order_release);
ready.notify_one(); // 必须有！
// 消费者
ready.wait(false, std::memory_order_acquire); // 等待从 false → true
use(data);
性能差异和隐蔽陷阱
std::atomic::wait 在命中 futex 时几乎零开销（用户态不循环），但一旦 notify 丢失（比如 notify 发生在 wait 之前），就会永久阻塞 —— 这叫“ABA 类等待丢失”，没有内置防护。
轮询方案看似低效，但在短等待（wait 在长等待（>1ms）+ 正确配对 notify 时，功耗和调度延迟明显更优。
最容易被忽略的一点：std::atomic::wait 的参数是**期望值**，不是谓词。它只检查当前值是否等于传入值，然后阻塞；它不会重试判断逻辑。所以不能写 flag.wait(true) 等待变为 true —— 必须写 flag.wait(false) 等待从 false 变更为其他值，再用 load 二次确认。
