互斥锁所有权是否严格仅移交给在解锁之前请求锁定的线程？答案

【问题标题】：Is mutex ownership handed off strictly only to threads which have requested for the lock prior to unlocking?互斥锁所有权是否严格仅移交给在解锁之前请求锁定的线程？
【发布时间】：2017-01-05 13:14:57
【问题描述】：

情况：

线程 1 当前拥有互斥锁。
虽然线程 1 保留互斥锁的所有权，但线程 2 请求相同的锁。
线程 1 解锁。

此时，另一个线程（比如线程 3）是否可以突然进入并请求锁并获取它（如下所示）？或者 POSIX 是否保证在解锁互斥锁时已经在等待所述互斥锁的线程获取互斥锁？

pthread_mutex_unlock() 的手册页指出 -

如果在 mutex 引用的 mutex 对象上有线程阻塞当调用 pthread_mutex_unlock() 时，导致互斥锁变为可用，调度策略应确定哪个线程应获取互斥体。

这似乎是说线程 3 无法突入并获取互斥锁，尽管我并不完全确定。

【问题讨论】：

标签： multithreading pthreads

【解决方案1】：

在解锁的那一刻，所有试图锁定互斥锁的线程都将状态从 BLOCKED 更改为 READY。一个特定的实现可能会确保这些线程中只有一个会获得互斥锁，但此时任何线程都可能会尝试锁定互斥锁。

因此，线程 3 可能能够在某些实现（或者甚至在所有实现中）先于其他任何人获得互斥锁。

【讨论】：

【解决方案2】：

不能保证踏板会按照它们请求的顺序被授予锁。

【讨论】：

我不是在问是否基于 FCFS 获取锁。在场景LOCK(m, t1) -> ACQUIRE(m, t1) -> LOCK(m, t2) -> LOCK(m, t3) -> UNLOCK(m, t1) -> LOCK(m, t4)。在UNLOCK(m, t1)，t2 和 t3 之间肯定会发生争用（即可能不是 FCFS）。我的问题是，t4 是否过于争用锁（t4 在 'm' 被解锁后发出锁请求）？
这涉及到很多东西，进程调度机制，特定的互斥管理实现等等。如果我们忽略这一切，并且在 UNLOCK(m, t1) 之后没有 ACQUIRE，那么它是合乎逻辑的假设 LOCK(m, t4) 将竞争互斥锁。说到这里，我很好奇，您要解决的问题是什么？
与其说是尝试解决问题，不如说是尝试了解 POSIX 互斥锁和线程的预期行为方式。

【解决方案3】：

没有这样的保证。

只有当线程 1 的解锁与线程 3 的锁竞争时，才会出现这种情况，在这种情况下，锁在解锁之前或稍晚之间确实没有区别。

【讨论】：

你确定吗？我问是因为在 pthread_cond_signal() 和 pthread_cond_wait() 的情况下，对于这个 swoop in 问题存在一些混淆。 David Butenhof 阐明 pthread_cond_signal() 仅唤醒在信号之前调用 pthread_cond_wait() 的线程。 austingroupbugs.net/view.php?id=609
在 pthread_mutex_unlock() 的情况下，我解释手册页的方式是，在这里也可以预期相同的行为，即 pthread_mutex_unlock() 尝试解锁已经在等待它的线程（首先），即“原子解锁”。
这里的区别在于，对于pthread_cond_signal()在持有与条件变量关联的互斥锁时调用的情况，解除阻塞和等待是由锁来排序的——所以谈论是否等待发生在信号之前或之后。在您的示例中情况并非如此-线程 1 解锁和线程 3 锁定之间没有强加的排序约束。（尽管也许您可以通过使用第二个互斥体来创建这样的约束）。
我会指出你甚至不需要第三个线程 - 你可以让线程 1 再次尝试重新锁定互斥锁，事实上，如果你这样做，你可以很容易地观察到同样的情况线程能够解锁和重新锁定互斥锁数千次，而另一个线程被阻塞等待它。
不，我提供的链接中的讨论仅涉及 pthread_cond_signal() ，无论它是否在锁的保护下被调用。如果您在讨论结束时阅读 (geoffclare)，您将看到 pthread_cond_signal() 手册页的更新语言。粘贴在下面 -