lock（mutex） 实现通常尝试确定互斥锁被锁定了多长时间以及锁定在哪个内核上吗？如果不是，为什么不呢？

Do lock(mutex) implementations usually try to determine for how long a mutex was locked and on which core? If not, why not?

提问人：curiousguy 提问时间：12/2/2019 最后编辑：curiousguy 更新时间：12/5/2019 访问量：68

问：

当互斥锁的锁定（或try_lock）函数发现互斥锁已经被锁定（可能被另一个线程锁定）时，它是否可以尝试确定拥有的线程是否（或最近）在另一个内核上运行？

知道所有者是否正在运行可以指示线程仍然持有锁的可能原因（为什么它无法解锁它）：如果拥有互斥锁的线程是“可运行”的（等待可用的核心和时间片）或“休眠”或等待 I/O...那么显然在互斥锁上旋转是没有用的。

我知道非递归、非“安全”、非优先级继承互斥锁（我称之为“匿名”互斥锁：实际上可以由另一个线程解锁的互斥锁，因为它们只是普通信号量）携带尽可能少的信息，但可以肯定的是，对于那些知道锁定线程标识的“拥有”互斥锁来说，这可以确定。

另一个更有用的信息是它被锁定了多少时间，但这可能需要在互斥对象中添加一个字段。

有没有这样做过？

多线程 优化 与语言无关的 互斥锁 旋转锁

评论

0赞 Tsyvarev 12/2/2019
“这是常见的做法吗？如果不是，为什么不呢？ - 互斥锁管理中既不使用互斥锁的所有者运行状态，也不使用互斥锁拥有的时间。您为什么希望收集此类信息？
0赞 curiousguy 12/2/2019
@Tsyvarev “你为什么希望收集这样的信息？”正如我所写的：“给出互斥锁仍然被锁定的原因。
0赞 Tsyvarev 12/2/2019
“指示互斥锁仍被锁定的原因”是什么意思？只要互斥锁的所有者当前是否在运行，互斥锁就会被视为已锁定。
0赞 Jeremy Friesner 12/2/2019
我不认为这是常见的做法，因为实现该功能会降低效率，而互斥实现者不愿意这样做。无论如何，收集到的信息对程序几乎没有用处——一个设计良好的程序应该正常工作，无论谁持有互斥锁或为什么持有互斥锁。如果需要调试有缺陷的程序（例如，由于线程长时间或无限期地持有互斥锁而导致死锁的程序），可以使用调试器来查看哪些线程当前位于它们将持有锁的代码位置，或者显式检测您的代码。
1赞 Jeremy Friesner 12/2/2019
你总是可以编写自己的互斥锁包装类，将调用者的线程 ID 记录为其 lock（） 方法的一部分——但你问题的答案仍然是“可能，否”和“因为没有人发现这样做值得增加运行时成本”。

答： 暂无答案

上一个：让读者知道作者写完了，等待读者读完

下一个：使用测试和设置原子操作实现互斥锁：它是否适用于超过 2 个线程？