关于互斥锁与信号量的选择疑问：为何使用std::mutex而非信号量，能否用std::binary_semaphore替代它？

嘿，这个问题问得挺到位的！我当初刚接触并发编程的时候也纠结过这个点——毕竟看资料说std::binary_semaphore初始化为1时，好像能和std::mutex一样实现临界区保护，甚至可能更高效，但实际写代码的场景里，大家还是更偏爱std::mutex，主要有这么几个关键原因：

• 所有权语义的安全性：std::mutex是带所有权绑定的——哪个线程加的锁，就必须由哪个线程解锁。很多编译器和调试工具还会帮你检查这个规则，要是你不小心在别的线程解锁了，直接就给你报错，能提前揪出bug。但std::binary_semaphore没这个限制，任何线程都可以调用post()，哪怕它从来没调用过wait()。举个例子：线程A刚获取了信号量进入临界区，线程B误调用了post()，这就会导致信号量计数变成2，后续其他线程可能直接闯进来，临界区的保护就失效了，这种bug排查起来特别头疼。

• 和条件变量的天然适配：如果你需要实现“等待某个条件满足”的逻辑，std::mutex和std::condition_variable是标准搭档——你必须用std::unique_lock<std::mutex>来配合条件变量使用，这是C++标准规定的。但std::binary_semaphore没法直接和条件变量协作，硬要凑在一起用的话，代码会变得非常别扭，还容易引入新的并发问题。

• RAII的便捷性：C++标准库给std::mutex配套了std::lock_guard和std::unique_lock这些RAII工具，能自动管理锁的生命周期——不管是正常执行完代码，还是中途抛出异常，锁都会自动释放，完全不用你手动记着解锁。但std::binary_semaphore没有官方的RAII包装，你得自己写封装类，一不小心就会漏写post()，或者在异常场景下没释放，导致死锁。

• 语义清晰性与可读性：std::mutex的语义非常明确——就是用来保护临界区，防止多个线程同时修改共享数据。其他开发者看到std::mutex，一眼就懂这段代码的意图。但std::binary_semaphore的用途更广泛，既可以做互斥，也能用来做线程间的同步通知（比如生产者-消费者模型里的信号传递）。如果用它来替代std::mutex，别人看代码的时候可能会疑惑：“这里用信号量是不是有特殊的同步逻辑？”反而增加了理解成本。

当然啦，也不是说std::binary_semaphore完全不能用在互斥场景——如果你的场景确实需要跨线程释放的能力（比如一个线程等待某个操作完成，另一个线程完成后触发释放），那它会是更合适的选择。但绝大多数普通的临界区保护场景，std::mutex的安全性、便捷性和可读性都更胜一筹，性能差异在实际业务中基本可以忽略不计。

备注：内容来源于stack exchange，提问作者Baruch