不能直接用 std::atomic 实现信号量，因其缺乏阻塞等待能力，仅支持原子读写/CAS/加减，需配合 yield 或 futex 实现轻量等待；整型 atomic 不受 ABA 影响，但必须用 compare_exchange_weak 检查非零再扣减，避免欠信号。
为什么不能直接用 std::atomic 实现信号量？
因为 std::atomic 本身不提供「等待直到值大于零」的能力，它只支持读、写、CAS、加减等原子操作，但没有阻塞或条件等待语义。直接轮询 load() 会浪费 CPU；而用 std::condition_variable 又得搭配互斥锁，失去「无锁」初衷。真正高效简易的实现，必须在原子操作基础上，合理引入轻量级等待（如 std::this_thread::yield() 或 futex 级别系统调用），同时避免锁竞争。
std::atomic<int></int> + 自旋等待是否够用？
对低争用、短等待场景（比如线程池任务计数、资源池令牌发放），纯自旋是可行且高效的。但要注意三点：
- 必须用
memory_order_acquire读、memory_order_release写，否则可能看到过期值或重排导致逻辑错误 - 空转太久会拖垮性能，建议加 yield 或指数退避：第一次失败后
std::this_thread::yield()，连续多次失败后 sleep(1ns) 逐步加长 - 不要用
while (count.load() 简单死等 —— 如果初始值为 0，且没人 post，就真死锁了；应加超时或中断点（哪怕只是检查 <code>std::this_thread::interrupted()）
示例 acquire：
bool try_acquire() {
int expected = count.load(std::memory_order_acquire);
while (expected > 0) {
if (count.compare_exchange_weak(expected, expected - 1,
std::memory_order_acq_rel,
std::memory_order_acquire)) {
return true;
}
// expected 被更新为当前值，继续循环
}
return false;
}如何避免 ABA 问题影响信号量计数？
信号量本质是计数器，不是指针，所以标准整型 std::atomic<int></int> 不受 ABA 影响 —— 它只关心数值是否匹配，不涉及地址复用。只要用 compare_exchange_weak 做 CAS 更新，数值变化逻辑自洽，就不需要额外处理 ABA。但注意：若用 fetch_add(-1) 直接减，可能在值为 0 时误减成负数（即“欠信号”）。正确做法是先读再 CAS，确保不越界。
立即学习“C++免费学习笔记（深入）”；
- 禁止：
count.fetch_add(-1, std::memory_order_acq_rel)—— 无条件减，破坏语义 - 推荐：
compare_exchange_weak循环，显式检查 >= 1 再扣减 - 若需高性能批量 acquire（如一次拿 3 个），可改用
fetch_sub+ 回滚：先fetch_sub(n)，再判断结果是否>= n，否则加回去
要不要封装成 RAII 的 ScopedSemaphore？
可以，但要小心析构时机和异常安全。典型陷阱是：构造时 acquire 成功，中途抛异常，析构没被调用，导致泄漏。必须确保 acquire 是 nothrow，或用 try_acquire + 显式判断，再进 RAII 包装。
- 构造函数不应抛异常；失败时返回
std::nullopt或设valid_ = false - 析构函数里只做 release，且必须用
memory_order_relaxed（因为 release 不依赖顺序，仅需可见性） - 移动语义要禁用或明确转移所有权，避免 double-release
简单示意：
struct ScopedSemaphore {
ScopedSemaphore(Semaphore& s) : sem_(s), acquired_(s.try_acquire()) {}
~ScopedSemaphore() { if (acquired_) sem_.release(); }
explicit operator bool() const { return acquired_; }
private:
Semaphore& sem_;
bool acquired_;
};真正难的是平衡：自旋太狠耗 CPU，挂起太重失简易；用系统原语（如 Linux futex）能真正高效，但跨平台成本高。多数项目里，带 yield 的 CAS 循环已足够 —— 关键是别把它当通用同步原语，而是限定在可控争用场景下使用。
