pthread_mutex_lock 和 pthread_mutex_lock 在另一个线程中

pthread_mutex_lock and pthread_mutex_lock in another thread

我在一个线程中调用了一个 pthread_mutex_lock(&th) 然后我想在另一个线程中解锁互斥量 pthread_mutex_unlock(&th)

可以吗?

或者应该在同一个线程中解锁互斥锁?

应该在同一个线程中解锁。来自手册页:"If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results." (http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_mutex_lock.html)

我只想补充 Guijt 的回答: 当线程锁定互斥量时,假定它在临界区内。如果我们允许另一个线程解锁该互斥锁,第一个线程可能仍在临界区内,从而导致问题。

我可以看到您的问题的几种解决方案:

选项 1:重新考虑您的算法

尝试了解为什么需要从不同的线程解锁,看看是否可以在锁定线程中完成解锁。这是最好的解决方案,因为它通常会生成最容易理解的代码,并且最容易证明它确实在做您认为它在做的事情。多线程编程这么复杂,为了这么简单值得付出的代价应该是相当高的。

选项 2:将线程与事件同步

有人可能会争辩说这只是实现上述选项 1 的一种方法。这个想法是,当锁定线程完成临界区时,它不会出去做任何事情,而是等待一个事件。当第二个线程希望释放锁时,它会发出事件信号。然后第一个线程释放锁。

此过程的优点是线程 2 不会无意中过早释放锁。

选项 3:不使用互斥锁

如果以上选项都不适合您,您很可能没有使用互斥体进行互斥,而是用于同步。如果是这种情况,您可能使用了错误的结构。

最像互斥量的构造是信号量。事实上,多年来 Linux 内核没有互斥量,声称它只是一个最大值为 1 的信号量。信号量与互斥量不同,不需要相同的线程锁定和释放。

sem_init 上的 RTFM 以及如何使用它的朋友。

请注意,您必须首先对问题建模,然后才选择要使用的正确同步构造。如果你反过来做,你几乎肯定会引入很多很难找到和修复的错误。

使用 Mutex 的全部目的是在关键部分实现互斥,并由内核跟踪所有权。所以必须在获得它的同一个线程中解锁互斥锁