不能直接用 std::atomic 模拟信号量，因其缺乏阻塞语义；需结合 futex 或条件变量实现等待/唤醒，计数器用 std::atomic 管理，确保高效与正确性。
为什么不能直接用 std::atomic 模拟信号量？
因为 std::atomic 本身不提供“等待直到值大于 0”这种阻塞语义——它只支持无锁的读、写、CAS、fetch_add 等操作。直接轮询 load() 会空转耗 CPU，而加锁又违背了“原子变量高效”的初衷。真正可行的路径是：用 std::atomic 管理计数，但把阻塞逻辑交给系统原语（如 futex 或条件变量），否则就不是生产可用的信号量。
Linux 下用 futex + std::atomic<int></int> 实现轻量信号量
这是最接近“基于原子变量”的高效实现：计数器用 std::atomic<int></int>，阻塞/唤醒走内核级 futex，避免用户态忙等。关键点在于：只有在计数器为 0 时才触发 futex_wait，且每次 post() 都需检查是否有等待者并调用 futex_wake。
-
futex地址必须对齐且生命周期覆盖整个信号量使用期（通常用std::atomic<int></int>成员变量地址） - 调用
syscall(SYS_futex, ...)时，op参数要用FUTEX_WAIT_PRIVATE（单进程）或FUTEX_WAIT（跨进程），别漏掉_PRIVATE后缀导致性能下降 -
wait()中的 CAS 必须用compare_exchange_strong循环重试，防止 ABA 导致误唤醒 - 示例核心逻辑：
int cur = count_.load();<br>while (cur == 0) {<br> if (count_.compare_exchange_strong(cur, -1)) {<br> syscall(SYS_futex, &count_, FUTEX_WAIT_PRIVATE, -1, nullptr);<br> cur = count_.load();<br> }<br>}</code>
跨平台妥协方案：用 std::mutex + std::condition_variable 封装原子计数
如果你不需要极致性能，或目标平台不支持 futex（如 Windows/macOS），那就老实用标准库同步原语——但计数器仍保持 std::atomic<int></int>，仅用于无锁读取状态（比如 try_wait() 判断是否可立即获取）。这样既保留原子变量的轻量读能力，又把阻塞交给成熟实现。
-
wait()和post()内部必须用std::unique_lock保护临界区，但try_wait()可只读count_.load()并 CAS 尝试减一，失败即返回 false - 注意
std::condition_variable::notify_one()不保证唤醒成功——被唤醒线程仍要重新检查计数，所以循环条件不能省 - Windows 上
WaitForSingleObject替代futex时，需额外维护一个HANDLE，无法做到纯原子变量驱动
std::atomic_flag 能不能用来做二值信号量？
可以，但仅限于最简化的“有/无”场景（即 binary semaphore），且必须接受它不带计数能力。常见错误是试图用 std::atomic_flag 模拟 >1 的资源数——它只有 test_and_set() 和 clear()，没法表示“还剩 2 个可用”。如果真只需要互斥访问某资源一次，std::atomic_flag 是最小开销选择；但凡涉及复用、计数、超时，就得升级到完整实现。
立即学习“C++免费学习笔记（深入）”；
容易忽略的是：默认构造的 std::atomic_flag 处于未定义状态，必须显式用 ATOMIC_FLAG_INIT 或 C++20 的 std::atomic_flag flag{} 初始化，否则 test_and_set() 行为未定义。
