std::atomic::notify_all 不存在，它是 std::condition_variable 的成员函数；原子类型不提供等待/唤醒机制，需配合 condition_variable 使用，或在 C++20 中使用 std::atomic_notify_all。
std::atomic::notify_all 为什么不能直接调用
因为 std::atomic::notify_all 不是 std::atomic 的成员函数——它根本不存在。C++ 标准库中，notify_all 属于 std::condition_variable，而原子类型（如 std::atomic<bool></bool> 或 std::atomic<int></int>）本身不提供线程等待/唤醒机制。
如果你看到代码里写了 flag.notify_all()，编译器会直接报错：error: 'notify_all' is not a member of 'std::atomic<bool>'</bool>。这是最常踩的坑：混淆了原子操作和条件变量的职责。
想“用原子变量唤醒线程”，实际要靠 std::condition_variable + std::atomic 配合
典型模式是：用 std::atomic 做轻量状态标记（比如就绪、完成），用 std::condition_variable 承担阻塞等待和批量唤醒逻辑。原子变量负责无锁更新，条件变量负责安全挂起和通知。
关键点：
立即学习“C++免费学习笔记（深入）”；
-
std::condition_variable::notify_all()必须在持有对应std::unique_lock<:mutex></:mutex>的前提下调用，否则行为未定义 -
std::atomic变量（如ready_flag）通常只在修改后、notify_all()前更新，确保等待线程醒来后能立刻读到新值 - 等待端必须用
cv.wait(lock, [&]{ return ready_flag.load(); });这种带谓词的写法，避免虚假唤醒
示例片段：
std::atomic<bool> ready_flag{false};
std::mutex mtx;
std::condition_variable cv;
// 等待线程
std::unique_lock<std::mutex> lock(mtx);
cv.wait(lock, [&]{ return ready_flag.load(); });
// 通知线程（在修改标志后）
ready_flag.store(true);
lock.lock(); // 注意：这里需重新获取锁（或复用已有锁）
cv.notify_all();
lock.unlock();
std::atomic_flag 能 sleep/wake 吗？不能，但可轮询 + yield
std::atomic_flag 是唯一保证无锁的原子类型，但它只有 test_and_set() 和 clear()，没有等待能力。若强行“等待”，只能用忙等：
- 循环调用
flag.test()或flag.test_and_set() - 每次迭代加
std::this_thread::yield()减少 CPU 占用 - 绝对不要用
std::this_thread::sleep_for(1ms)—— 延迟不可控，且唤醒不及时
这种模式只适合极短等待（微秒级）、对延迟极度敏感且能接受 CPU 占用的场景。绝大多数情况应优先选 condition_variable。
std::atomic_wait / std::atomic_notify 在 C++20 中可用，但有平台限制
C++20 引入了 std::atomic_wait 和 std::atomic_notify_one/std::atomic_notify_all，它们是真正基于原子变量的等待/唤醒原语，无需 mutex 或 condition_variable。
但要注意：
- 目前仅部分平台支持：Linux（glibc ≥ 2.34 + kernel ≥ 5.3）、Windows（MSVC 19.29+）、macOS（不支持）
- 必须搭配
std::atomic的整型特化（如std::atomic<int></int>、std::atomic<bool></bool>），std::atomic_flag不支持 - 调用前需确保原子对象处于可等待状态（例如先
store()再wait()）
示例（C++20）：
std::atomic<bool> done{false};
// 等待端
done.wait(false); // 等待值变为 true
// 通知端
done.store(true);
done.notify_all();
实际项目中，除非明确控制运行环境且已启用 C++20，否则仍建议用 condition_variable 方案——兼容性更稳，逻辑更清晰。
最容易被忽略的是：无论用哪种方案，「通知时机」必须严格在状态更新之后、且确保所有等待线程能看到该更新（内存序、锁保护、或 atomic_notify 的隐式同步）。漏掉这一步，唤醒就是无效的。
