因为 std::atomic 不支持阻塞等待，信号量的 wait() 需挂起线程，必须结合 mutex 和 condition_variable 实现；post() 用 fetch_add，但需处理虚假唤醒。
为什么不能直接用 std::atomic 实现完整信号量
因为 std::atomic 本身不提供「等待直到值大于零」的阻塞语义——它只支持无锁读写和 CAS，而信号量的 wait() 必须能挂起线程。硬用 while (count.load() 在高竞争或长等待时会浪费 CPU，且无法响应中断或超时。
所以高性能信号量必须组合两层：原子变量做快速路径（无竞争时直接 CAS），系统原语（如 futex、std::condition_variable）做慢路径（需等待时交由内核调度）。
常见错误是只用原子自旋，结果在低频信号到达时出现数十毫秒级延迟，或在线程被抢占后持续空转。
Linux 上用 futex 实现零拷贝等待路径
futex 是 Linux 内核提供的轻量同步原语，允许用户态原子变量与内核等待队列联动。关键在于：只有当原子计数器为 0 时才触发 futex_wait()，否则直接递减并返回。
立即学习“C++免费学习笔记（深入）”；
-
count用std::atomic<int></int>存储，初始值为信号量容量 -
wait()先fetch_sub(1, std::memory_order_acquire)，若结果 ≤ 0，说明已欠资源，调用syscall(SYS_futex, &count, FUTEX_WAIT_PRIVATE, 0, nullptr) -
post()先fetch_add(1, std::memory_order_release)，若结果 syscall(SYS_futex, &count, FUTEX_WAKE_PRIVATE, 1)
注意：FUTEX_WAIT_PRIVATE 和 FUTEX_WAKE_PRIVATE 表示线程私有（同进程内），避免跨进程开销；count 地址必须对齐且生命周期覆盖整个信号量使用期。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
跨平台方案中 std::condition_variable 的陷阱
用 std::mutex + std::condition_variable 虽可移植，但默认实现有隐式锁开销：每次 wait() 都需先 lock mutex，即使计数器足够也绕不开。这在高频 post()/wait() 场景下成为瓶颈。
缓解方法是加一层原子快速路径：
-
wait()先if (count.fetch_sub(1, std::memory_order_acquire) > 0) return; - 否则进入
std::unique_lock+cv.wait()，但唤醒后必须检查是否真被 post（spurious wakeup） -
post()先int prev = count.fetch_add(1, std::memory_order_release);，仅当prev 才 <code>cv.notify_one()
漏掉 prev 判断会导致过度唤醒，引发惊群；不检查 spurious wakeup 可能导致信号量计数错乱。
性能关键点：内存序与缓存行伪共享
std::memory_order_acquire 和 std::memory_order_release 是底线要求：确保 wait/post 操作前后访存不被重排，否则可能看到过期的 count 值或丢失唤醒。
更隐蔽的问题是伪共享：count 若和其他频繁修改的变量（如日志计数器、时间戳）落在同一缓存行，会因总线广播导致性能骤降。实测中，给 count 加 alignas(64) 或前后填充 64 字节，可提升 2–3 倍吞吐。
另外，futex 版本里不要用 std::atomic_thread_fence 替代系统调用的内存屏障——futex_wait/wake 本身已保证必要同步，多加 fence 只会拖慢。
