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