应使用满足平凡可复制、大小适配且平台支持的原子类型，配对 release-acquire 内存序，循环检查状态以避免通知丢失，并约束非原子数据访问顺序，同时确认目标平台原生支持 wait/notify。
如果您在实现多线程事件通知时希望避免互斥锁开销、消除上下文切换延迟，并确保等待行为严格绑定于原子变量状态变化，则可能遇到 std::atomic::wait 与 notify 调用无效、线程永不唤醒或读取到脏数据等问题。以下是解决此问题的步骤：
一、确保原子类型满足可等待前提
std::atomic::wait 仅对特定平凡可复制（trivially copyable）且平台支持的原子类型生效，如 std::atomic
1、确认模板参数 T 满足 std::is_trivially_copyable_v
2、避免使用 std::atomic
立即学习“C++免费学习笔记（深入）”；
3、显式声明原子变量时采用标准整型别名，例如使用 std::atomic_uint32_t 而非 std::atomic
二、正确配对 memory_order 与 store/wait 语义
wait 操作依赖内存序保证写入对等待线程可见；若 notify 前仅用 memory_order_relaxed 存储，唤醒可能丢失，因写入未同步到其他 CPU 缓存行。
1、在通知线程中执行 store 时必须使用至少 memory_order_release 顺序
2、在等待线程中调用 wait 前，必须先执行一次带 memory_order_acquire 或更强序的 load，以获取最新值并建立同步点
3、将 load 结果赋值给局部变量 expected，再传入 wait，禁止直接传入字面量如 flag.wait(0)
三、规避通知丢失（lost wakeup）的经典模式
std::atomic::notify_one 和 notify_all 不缓存通知，若 notify 发生在 wait 之前，该次通知即被丢弃；因此必须保证“状态更新 → 通知”发生在“检查状态 → 等待”逻辑之后，通常需循环检查加等待。
1、等待线程必须使用 do-while 或 while 循环包裹 wait，例如：while (flag.load(std::memory_order_acquire) == 0) { flag.wait(expected); }
2、每次 wait 返回后，立即重新 load 当前值并验证条件是否真正满足，不可假设唤醒即代表条件成立
3、通知线程应在修改所有相关共享数据后，再执行 store + notify，且 store 与 notify 之间不得插入可能被重排的非原子操作
四、防止虚假唤醒外的数据竞争
即使 wait 成功返回，若所反映的状态背后关联非原子数据（如结构体字段），而写线程未施加恰当内存序约束，读线程仍可能看到部分更新的撕裂状态。
1、若原子变量 flag 表示“struct Data d 已就绪”，则写线程必须在 d 的所有字段赋值完成后，再以 memory_order_release 存储 flag
2、读线程在 flag.wait() 返回后，必须以 memory_order_acquire 加载 flag，再访问 d 的字段
3、禁止仅用 std::atomic
五、适配不同平台的底层等待原语
std::atomic::wait 在 Linux 依赖 futex，在 Windows 依赖 WaitOnAddress，在 macOS（截至 C++20 实现）可能回退至 mutex+condvar 模拟；若目标平台不支持原生等待，行为将降级，影响性能与语义。
1、编译时检查 __cpp_lib_atomic_wait 是否定义，确认标准库支持该特性
2、Linux 环境下通过 strace -e trace=futex 验证程序是否实际触发 futex 系统调用
3、macOS 用户应避免在性能关键路径依赖 wait/notify，需查阅所用 libc++ 版本是否已启用 WaitOnAddress 替代方案
