我在一个线程中调用了pthread_mutex_lock(&th) 然后我想在另一个线程中解锁互斥锁pthread_mutex_unlock(&th)
有可能吗？
或者互斥锁应该在同一个线程中解锁？
【问题讨论】：
标签： c++ c linux multithreading pthreads
它应该在同一个线程中解锁。来自手册页：“如果线程尝试解锁尚未锁定的互斥锁或解锁的互斥锁，则会导致未定义的行为。” (http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_mutex_lock.html)
【讨论】：
我只是想补充 Guijt 的答案： 当一个线程锁定一个互斥体时，假定它在临界区中。如果我们允许另一个线程解锁该互斥锁，第一个线程可能仍然在临界区中，从而导致问题。
我可以看到几个解决您问题的方法：
选项 1：重新考虑您的算法
尝试了解为什么需要从其他线程解锁，并查看是否可以在锁定线程中完成解锁。这是最好的解决方案，因为它通常生成最容易理解的代码，并且最容易证明它实际上正在做你认为它正在做的事情。在多线程编程如此复杂的情况下，为这种简单性付出的代价应该是相当高的。
选项 2：将线程与事件同步
有人可能会争辩说，这只是实现上述选项 1 的一种方法。这个想法是，当锁定线程完成临界区时，它不会出去做任何事情，而是等待一个事件。当第二个线程希望释放锁时，它会发出事件信号。然后第一个线程释放锁。
此过程的优点是线程 2 不会无意中过早释放锁。
选项 3：不要使用互斥体
如果上述选项都不适合您，那么您很可能不是将互斥锁用于互斥，而是用于同步。如果是这种情况，您可能使用了错误的构造。
与互斥锁最相似的构造是信号量。事实上，多年来 Linux 内核都没有互斥锁，声称它只是一个最大值为 1 的信号量。信号量与互斥锁不同，它不需要相同的线程锁定和释放。
关于如何使用 sem_init 和朋友的 RTFM。
请注意，您必须先对问题进行建模，然后才能选择要使用的正确同步结构。如果反其道而行之，几乎肯定会引入很多非常难以发现和修复的错误。
【讨论】：
使用 Mutex 的全部目的是在关键部分实现互斥，并由内核跟踪所有权。所以互斥锁必须在获得它的同一个线程中解锁
【讨论】：