互斥锁（mutex）与二元信号量的适用场景对比咨询

虽然二者行为相似，但核心设计目标不同：互斥锁聚焦资源所有权与排他访问，二元信号量聚焦线程间同步事件。以下是具体的适用场景划分：

优先使用互斥锁的场景 #

• 保护独占式临界资源：当需要确保同一时间只有一个线程访问共享数据（如全局变量、链表、文件句柄）时，互斥锁是首选。它强制要求加锁的线程必须负责解锁，能避免其他线程误释放锁导致的安全问题。例如多线程更新同一个配置文件，用互斥锁包裹读写操作，可防止数据损坏。
• 需要避免优先级反转的实时场景：多数实时操作系统中的互斥锁支持优先级继承机制，能解决高优先级线程被低优先级线程阻塞的问题。而二元信号量通常没有这个特性，在实时系统中容易引发调度异常。
• 递归访问临界资源的场景：如果线程可能递归进入需要加锁的代码段（比如递归函数操作共享数据），可重入互斥锁（递归Mutex）允许同一线程多次加锁，不会造成死锁。而二元信号量若重复执行获取操作，会直接阻塞当前线程。

优先使用二元信号量的场景 #

• 线程间的单向同步通知：比如生产者-消费者模型中的单缓冲区场景：生产者生产数据后释放信号量，消费者等待信号量来获取数据。这里不需要所有权约束，任意线程都可以触发或等待信号，二元信号量的灵活性更适配。
• 中断服务程序（ISR）与线程的同步：ISR执行时间极短，不能被阻塞，因此无法使用互斥锁（互斥锁的加锁操作可能阻塞）。但ISR可以安全地释放二元信号量，线程则通过等待信号量来响应中断事件——这是二元信号量独有的典型场景。
• 多线程协作的同步触发：当需要多个线程中的任意一个完成任务后触发后续操作时，二元信号量更合适。比如三个线程分别处理不同任务，只要其中一个完成就通知主线程，主线程等待信号量即可，无需关心是哪个线程触发的。

内容的提问来源于stack exchange，提问作者Eric