Multithreading 锁（互斥锁）实现通常会尝试确定互斥锁被锁定的时间和在哪个内核上？若否，原因为何？

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

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

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

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

---

曾经这样做过吗？

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