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

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

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

厕所的例子是一个有趣的类比:

Mutex: Is a key to a toilet. One person can have the key - occupy the toilet - at the time. When finished, the person gives (frees) the key to the next person in the queue. Officially: "Mutexes are typically used to serialise access to a section of re-entrant code that cannot be executed concurrently by more than one thread. A mutex object only allows one thread into a controlled section, forcing other threads which attempt to gain access to that section to wait until the first thread has exited from that section." Ref: Symbian Developer Library (A mutex is really a semaphore with value 1.) Semaphore: Is the number of free identical toilet keys. Example, say we have four toilets with identical locks and keys. The semaphore count - the count of keys - is set to 4 at beginning (all four toilets are free), then the count value is decremented as people are coming in. If all toilets are full, ie. there are no free keys left, the semaphore count is 0. Now, when eq. one person leaves the toilet, semaphore is increased to 1 (one free key), and given to the next person in the queue. Officially: "A semaphore restricts the number of simultaneous users of a shared resource up to a maximum number. Threads can request access to the resource (decrementing the semaphore), and can signal that they have finished using the resource (incrementing the semaphore)." Ref: Symbian Developer Library

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

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

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

例如，你可以在互斥锁中启用错误检查属性。错误检查互斥量返回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");

答案可能取决于目标操作系统。例如，我所熟悉的至少一个RTOS实现允许对单个OS互斥量进行多个连续的“get”操作，只要它们都来自同一个线程上下文中。在允许另一个线程获得互斥量之前，多个get必须被相等数量的put替换。这与二进制信号量不同，对于二进制信号量，无论线程上下文如何，一次只允许一个get。

这种互斥锁背后的思想是，通过一次只允许一个上下文修改数据来保护对象。即使线程获得了互斥量，然后调用进一步修改对象的函数(并在自己的操作周围获得/放置保护互斥量)，这些操作仍然应该是安全的，因为它们都发生在单个线程下。

{
    mutexGet();  // Other threads can no longer get the mutex.

    // Make changes to the protected object.
    // ...

    objectModify();  // Also gets/puts the mutex.  Only allowed from this thread context.

    // Make more changes to the protected object.
    // ...

    mutexPut();  // Finally allows other threads to get the mutex.
}

当然，在使用此特性时，必须确保单个线程中的所有访问都是安全的!

我不确定这种方法有多普遍，或者它是否适用于我所熟悉的系统之外。有关这种互斥锁的示例，请参阅ThreadX RTOS。

最好的解决方案

唯一的区别是

1.互斥锁-> lock和unlock属于锁定互斥锁的线程。

2.信号量->没有所有权，即;如果一个线程调用semwait(s)，任何其他线程都可以调用sempost(s)来移除锁。

正如这里许多人提到的，互斥锁用于保护关键代码段(又名临界段)。你将在同一个线程中获得互斥锁(lock)，进入临界区，释放互斥锁(unlock)。

在使用信号量时，您可以让一个线程(例如线程a)等待一个信号量，直到另一个线程(例如线程B)完成任何任务，然后为线程a设置信号量以停止等待，并继续其任务。