“二进制信号量”是一种编程语言规避使用«信号量»，如«互斥量»。显然有两个非常大的区别:

你称呼他们的方式。 标识符的最大长度。

互斥锁只能由获得它的线程释放。 二进制信号量可以由任何线程(或进程)发出信号。

因此，信号量更适合于一些同步问题，如生产者-消费者。

在Windows上，二进制信号量更像事件对象而不是互斥对象。

它们不是一回事。它们有不同的用途! 虽然这两种类型的信号量都有一个满/空状态，并且使用相同的API，但它们的用法非常不同。

互斥信号量 互斥信号量用于保护共享资源(数据结构、文件等)。

互斥信号量由接收它的任务“拥有”。如果Task B尝试semGive一个当前由Task a持有的互斥锁，Task B的调用将返回一个错误并失败。

互斥对象总是使用以下顺序:

  - SemTake
  - Critical Section
  - SemGive

这里有一个简单的例子:

  Thread A                     Thread B
   Take Mutex
     access data
     ...                        Take Mutex  <== Will block
     ...
   Give Mutex                     access data  <== Unblocks
                                  ...
                                Give Mutex

二进制信号量 二进制信号量解决了一个完全不同的问题:

任务B被挂起等待某些事情发生(例如传感器被绊倒)。 传感器跳闸和中断服务程序运行。它需要通知任务的行程。 任务B应运行并对传感器跳闸采取适当的操作。然后继续等待。

   Task A                      Task B
   ...                         Take BinSemaphore   <== wait for something
   Do Something Noteworthy
   Give BinSemaphore           do something    <== unblocks

注意，对于二进制信号量，B获取信号量，a给出信号量是可以的。 同样，二进制信号量不能保护资源不被访问。信号量的给予和获取从根本上是分离的。 对于同一个任务来说，对同一个二进制信号量的给予和获取通常没有什么意义。

关于这个主题的好文章:

互斥量与信号量——第1部分:信号量 互斥量与信号量——第2部分:互斥量 互斥量与信号量——第3部分(最后一部分):互斥问题

来自第二部分:

The mutex is similar to the principles of the binary semaphore with one significant difference: the principle of ownership. Ownership is the simple concept that when a task locks (acquires) a mutex only it can unlock (release) it. If a task tries to unlock a mutex it hasn’t locked (thus doesn’t own) then an error condition is encountered and, most importantly, the mutex is not unlocked. If the mutual exclusion object doesn't have ownership then, irrelevant of what it is called, it is not a mutex.

修改问题是-互斥量和“二进制”信号量在“Linux”中的区别是什么?

答:以下是它们的区别 i)作用域——互斥锁的作用域在创建它的进程地址空间内，用于线程同步。而信号量可以跨进程空间使用，因此它可以用于进程间同步。

ii)互斥量是轻量级的，比信号量更快。Futex甚至更快。

iii)同一线程可以成功多次获得互斥锁，条件是互斥锁释放次数相同。其他线程试图获取将阻塞。而对于信号量，如果同一个进程试图再次获取它，它会阻塞，因为它只能获得一次。

You obviously use mutex to lock a data in one thread getting accessed by another thread at the same time. Assume that you have just called lock() and in the process of accessing data. This means that you don’t expect any other thread (or another instance of the same thread-code) to access the same data locked by the same mutex. That is, if it is the same thread-code getting executed on a different thread instance, hits the lock, then the lock() should block the control flow there. This applies to a thread that uses a different thread-code, which is also accessing the same data and which is also locked by the same mutex. In this case, you are still in the process of accessing the data and you may take, say, another 15 secs to reach the mutex unlock (so that the other thread that is getting blocked in mutex lock would unblock and would allow the control to access the data). Do you at any cost allow yet another thread to just unlock the same mutex, and in turn, allow the thread that is already waiting (blocking) in the mutex lock to unblock and access the data? Hope you got what I am saying here? As per, agreed upon universal definition!,

使用“互斥”就不会发生这种情况。没有其他线程可以解锁锁 在你的帖子里 使用“二进制信号量”可以实现这种情况。任何其他线程都可以解锁 线程中的锁

因此，如果您非常注重使用二进制信号量而不是互斥量，那么在锁定和解锁的“作用域”时应该非常小心。我的意思是，每个触及每个锁的控制流都应该触及一个解锁调用，也不应该有任何“第一次解锁”，而应该总是“第一次锁定”。