c++oding="utf-8" ?>
std::atomic_wait不能直接用于普通变量，因为它仅接受std::atomic类型指针，对裸指针或非原子变量调用会编译失败或触发未定义行为；它专为原子对象设计，要求变量生命周期长于等待操作且等待值必须与当前原子值严格匹配。
std::atomic_wait 为什么不能直接用在普通变量上
因为 std::atomic_wait 只接受 std::atomic 类型的指针，传入裸指针或非原子变量会触发未定义行为，甚至编译失败（比如 clang 会报 no matching function）。它不是“让任意变量可等待”，而是专为原子对象设计的休眠原语。
常见错误是试图对 int flag 或 bool ready 直接调用：std::atomic_wait(&flag, 0); —— 这根本过不了编译。
- 必须用
std::atomic<int></int>、std::atomic<bool></bool>等实例 - 变量生命周期需确保长于等待操作（比如不能在 lambda 中局部声明后传地址）
- 等待值必须与当前原子值一致，否则立即返回（这是“wait if equal”语义）
如何正确配对使用 std::atomic_wait 和 std::atomic_notify_one
通知和等待必须基于同一个 std::atomic 对象，且 notify 必须发生在 wait 阻塞之后（或同时），否则可能丢失信号。这不是条件变量那种“唤醒即重检”的模型，而是纯信号量式的一次性通知。
典型场景：线程 A 等待某个标志变为 true；线程 B 将其设为 true 并通知。
- 等待端：
std::atomic_wait(&ready, false);—— 当ready.load()==false时挂起 - 通知端：
ready.store(true, std::memory_order_relaxed); std::atomic_notify_one(&ready); - 注意 store 和 notify 的顺序不能颠倒；notify 前必须已更新值，否则等待线程看到旧值仍会休眠
-
std::atomic_notify_all适用于多个等待者，但开销略高，按需选用
std::atomic_wait 在 Windows 上默认不可用怎么办
MSVC 19.35+ 和 libc++ 17+ 支持，但 libstdc++（GCC 默认）直到 13.2 才实验性支持，且需链接 -latomic；Windows 上若用 MinGW 或旧版 MSVC，std::atomic_wait 可能只是空实现或直接抛异常。
运行时报 std::system_error: atomic_wait not supported 是常见现象。
- 检查编译器版本：
__cpp_lib_atomic_wait宏是否定义（C++20 起） - Linux 上优先用 GCC 13.2+ 或 Clang 16+ + libc++
- Windows 上建议用 MSVC 2022 17.8+，并确认项目设置中启用了 C++20 标准
- 生产环境若兼容性存疑，应 fallback 到
std::condition_variable或自旋+yield
比 condition_variable 快在哪？又有哪些隐藏代价
快的关键在于内核态等待：当原子值未变时，std::atomic_wait 可直接陷入 futex（Linux）或 WaitOnAddress（Windows），避免用户态忙等和 mutex 锁争抢。实测在低频通知、高并发等待场景下，延迟降低 3–10 倍。
但代价也很实在：
- 不提供 predicate 检查，必须自己保证等待前状态有效（比如先读一次值再 wait）
- 无法关联 mutex，也就没法做“wait + lock + check”这种安全模式，容易漏判虚假唤醒之外的逻辑竞态
- 调试困难：gdb 可能显示线程卡在
futex_wait，堆栈无业务上下文 - 过度依赖硬件特性，ARM64 上某些老芯片不支持 wait/notify 指令，会退化为自旋
真正需要它的场景其实很窄：高频事件分发（如 lock-free ring buffer 的 consumer 等待新数据）、实时性敏感且通知极少的模块。多数业务逻辑还是老实用 std::condition_variable 更稳。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
