在理论层面上，它们在语义上并无不同。您可以使用信号量实现互斥量，反之亦然(参见这里的示例)。在实践中，实现是不同的，它们提供的服务也略有不同。

实际的区别(就围绕它们的系统服务而言)在于互斥锁的实现旨在成为一种更轻量级的同步机制。在oracle语言中，互斥锁被称为锁存器，而信号量被称为等待。

在最低级别，他们使用某种原子测试和设置机制。它读取内存位置的当前值，计算某种条件，并在一条不能中断的指令中写入该位置的值。这意味着您可以获得一个互斥锁，并测试是否有人在您之前拥有它。

典型的互斥量实现有一个进程或线程执行test-and-set指令，并评估是否有其他东西设置了互斥量。这里的关键点是与调度程序没有交互，因此我们不知道(也不关心)谁设置了锁。然后，我们要么放弃我们的时间片，并在任务重新调度时再次尝试它，要么执行自旋锁。自旋锁是这样一种算法:

Count down from 5000:
     i. Execute the test-and-set instruction
    ii. If the mutex is clear, we have acquired it in the previous instruction 
        so we can exit the loop
   iii. When we get to zero, give up our time slice.

当我们完成执行受保护的代码(称为临界区)时，我们只需将互斥量的值设置为零或其他表示“清除”的值。如果有多个任务试图获取互斥量，那么下一个计划在互斥量释放后的任务将获得对资源的访问权。通常情况下，您可以使用互斥来控制同步资源，在这种资源中，只需要在很短的时间内对其进行独占访问，通常是对共享数据结构进行更新。

A semaphore is a synchronised data structure (typically using a mutex) that has a count and some system call wrappers that interact with the scheduler in a bit more depth than the mutex libraries would. Semaphores are incremented and decremented and used to block tasks until something else is ready. See Producer/Consumer Problem for a simple example of this. Semaphores are initialised to some value - a binary semaphore is just a special case where the semaphore is initialised to 1. Posting to a semaphore has the effect of waking up a waiting process.

一个基本的信号量算法如下所示:

(somewhere in the program startup)
Initialise the semaphore to its start-up value.

Acquiring a semaphore
   i. (synchronised) Attempt to decrement the semaphore value
  ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.

Posting a semaphore
   i. (synchronised) Increment the semaphore value
  ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.  
 iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.

在二进制信号量的情况下，两者之间的主要实际区别是围绕实际数据结构的系统服务的性质。

编辑:正如evan正确地指出的那样，自旋锁会降低单个处理器的速度。你只能在多处理器上使用自旋锁，因为在单处理器上，持有互斥锁的进程永远不会在另一个任务运行时重置它。自旋锁只在多处理器架构上有用。

虽然二进制信号量可以用作互斥量，但互斥量是一个更具体的用例，因为只有锁定了互斥量的进程才应该解锁它。这种所有权限制使我们有可能对以下情况提供保护:

意外释放 递归死锁 任务死亡死锁

这些限制并不总是存在，因为它们降低了速度。在代码开发期间，您可以暂时启用这些检查。

例如，你可以在互斥锁中启用错误检查属性。错误检查互斥量返回EDEADLK，如果你试图锁定同一个互斥量两次，如果你解锁了一个不是你的互斥量，返回EPERM。

pthread_mutex_t mutex;
pthread_mutexattr_t attr;
pthread_mutexattr_init (&attr);
pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_ERRORCHECK_NP);
pthread_mutex_init (&mutex, &attr);

一旦初始化，我们可以将这些检查放在我们的代码中，就像这样:

if(pthread_mutex_unlock(&mutex)==EPERM)
 printf("Unlock failed:Mutex not owned by this thread\n");

在Windows上，互斥量和二进制信号量之间有两个区别:

互斥锁只能由拥有所有权的线程释放，即之前调用Wait函数的线程(或在创建互斥锁时获得所有权的线程)。任何线程都可以释放信号量。 线程可以在互斥锁上重复调用等待函数而不会阻塞。但是，如果你在一个二进制信号量上调用了两次等待函数，而中间没有释放信号量，线程就会阻塞。

在窗口，差异如下所示。 MUTEX:成功执行等待的进程必须执行一个信号，反之亦然。二进制信号量:不同的进程可以在一个信号量上执行等待或信号操作。

The basic issue is concurrency. There is more than one flow of control. Think about two processes using a shared memory. Now only one process can access the shared memory at a time. If more than one process accesses the shared memory at a time, the contents of shared memory would get corrupted. It is like a railroad track. Only one train can run on it, else there would be an accident.So there is a signalling mechanism, which a driver checks. If the signal is green, the train can go and if it is red it has to wait to use the track. Similarly in case of shared memory, there is a binary semaphore. If the semaphore is 1, a process acquires it (makes it 0) and goes ahead and accesses it. If the semaphore is 0, the process waits. The functionality the binary semaphore has to provide is mutual exclusion (or mutex, in short) so that only one of the many concurrent entities (process or thread) mutually excludes others. It is a plus that we have counting semaphores, which help in synchronizing multiple instances of a resource.

互斥是信号量提供的基本功能。现在在线程上下文中，我们可能有不同的名称和语法。但基本概念是相同的:如何在并发编程中保持代码和数据的完整性。在我看来，像所有权和相关检查这样的东西是由实现提供的改进。

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!,

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

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