C++怎么使用信号量_C++同步机制教程【并发】

std::counting_semaphore是c++20标准化的轻量级计数信号量，仅支持acquire()、release()和带超时的try_acquire_for()，不兼容posix/windows传统信号量，需编译器支持（gcc 11+/clang 12+/msvc 19.30+），初始化值必须非负，不可替代mutex，无跨进程能力，acquire()不响应中断。

std::counting_semaphore 在 C++20 中怎么用

它不是“信号量”的传统实现，而是标准化的轻量级计数信号量，仅支持 acquire()、release() 和带超时的 try_acquire_for()。不支持 POSIX 风格的 sem_wait() 或 Windows 的 ReleaseSemaphore() —— 想直接替换老代码会失败。

使用前确认编译器支持：GCC 11+（需 -std=c++20）、Clang 12+、MSVC 19.30+。否则编译报错 ‘counting_semaphore’ is not a member of ‘std’。

• 初始化值必须 ≥ 0，传负数触发编译错误：std::counting_semaphore 合法，但 std::counting_semaphore 不合法
• 构造时传入初始计数值，比如 std::counting_semaphore sem{5} 表示最多允许 5 个线程同时通过
• acquire() 阻塞直到计数 > 0，然后原子减 1；release() 原子加 1，不检查上限（可超过初始值）
• 别在析构时还有线程阻塞在 acquire() 上，否则行为未定义 —— 必须确保所有等待线程已退出或被唤醒

为什么不能用 std::binary_semaphore 替代互斥锁

std::binary_semaphore 是 std::counting_semaphore 的别名，只提供二值同步，不带所有权语义、不记录哪个线程持有、也不支持递归获取。它不能替代 std::mutex 保护临界区。

典型误用：用 binary_semaphore “锁住”一段数据操作，结果多个线程交替执行，出现竞态。因为它不阻止其他线程进入临界区 —— 只是控制“通行次数”，而非“排他访问”。

立即学习“C++免费学习笔记（深入）”；

• 适合场景：线程间事件通知（如生产者发信号、消费者响应），或限制并发数（如最多 3 个 I/O 线程同时运行）
• 不适合场景：保护共享变量读写、实现 RAII 锁（它没有 lock()/unlock() 接口，也没 std::scoped_lock 支持）
• 若真需要类 mutex 行为，请用 std::mutex + std::unique_lock，而不是硬套 binary_semaphore

Windows / linux 兼容性差在哪

C++20 的 std::counting_semaphore 是纯用户态实现（通常基于 futex 或类似原语），不调用系统 sem_init() 或 CreateSemaphore()。这意味着它无法跨进程共享，也不能与旧 C API 信号量交互。

如果你的项目要兼容 pre-C++20 编译器，或需跨进程同步，这条路走不通。强行封装会丢失原子性保证或引入竞态。

• Linux 下不等价于 sem_t：后者支持 sem_post() 和 sem_wait()，可设为进程间共享（sem_open()），前者完全不可见
• Windows 下不等价于 HANDLE 类型的信号量：无法用 WaitForSingleObject() 等待，也不能被调试器识别为内核对象
• 移植旧代码时，别试图把 sem_wait(&s) 直接换成 s.acquire() —— 初始化、销毁、错误处理逻辑全不同

acquire() 被中断时怎么处理

std::counting_semaphore::acquire() 不响应 POSIX 信号（如 SIGINT），也不会因线程被 std::jthread::request_stop() 中断而返回 false 或抛异常。它是“安静阻塞”，没提供取消点。

这意味着：无法用它实现带超时或可取消的等待 —— 除非你用 try_acquire_for() 主动轮询，但这会增加 CPU 占用和延迟不确定性。

• 需要响应中断？改用 std::condition_variable + std::stop_token 组合，手动管理计数逻辑
• 需要精确超时？try_acquire_until() 或 try_acquire_for() 是唯一选择，但要注意它们返回 bool，失败时不抛异常
• 别依赖异常传递来“跳出等待”——它根本不会抛异常，即使线程被请求停止

信号量不是万能胶，它解决的是资源配额问题，不是通用同步原语。用错地方，比不用还难 debug。