boost：如何监视互斥锁的状态并在死锁时强制释放[重复]答案

【问题标题】：boost: how to monitor status of mutex and force release on deadlock [duplicate]boost：如何监视互斥锁的状态并在死锁时强制释放[重复]
【发布时间】：2012-10-30 02:53:44
【问题描述】：

可能重复：
Example for boost shared_mutex (multiple reads/one write)?

我正在尝试使用 boost 中的 shared_lock 和 unique_lock 库来实现对资源的基本读写锁。但是，一些访问资源的线程可能会简单地崩溃。我想创建另一个进程，给定一个互斥锁，监视互斥锁并跟踪哪些进程锁定了资源以及每个进程锁定了多长时间。如果进程拥有锁超过给定的时间段，该进程还将强制进程释放其锁。

非常感谢任何有关如何解决此问题的建议！

【问题讨论】：

消除崩溃将是首选方法。对崩溃的创可贴很少有好的结果。
您应该将容易崩溃的代码段包装在try catch 块中，并尽可能释放那里的关键资源。
try/catch 是针对编程错误，而不是针对崩溃（除非您在谈论 Windows 结构化异常处理，这是另一种野兽）。
@PeeterJoot 你是完全正确的：不知何故，我假设崩溃是未捕获的异常。如果是这种情况，采取一些预防措施并没有什么坏处，但确实有更多可能的原因导致线程自身崩溃，而不仅仅是异常。
好吧，服务器崩溃仍然可能发生，而且无法避免。 @DavidTitarenco 给出的示例没有帮助，因为在崩溃时系统会获取 SIGSEGV，并且没有调用析构函数，因此锁不会自动解锁，因为它超出了范围。

标签： c++ multithreading boost mutex

【解决方案1】：

如果你强制持有锁的进程释放，那么你就破坏了锁的目的。想象一下 mutex pSharedMem->m 保护对某些内存的访问 pSharedMem->mystuff

pSharedMem->m.get_lock() ;
sleep( LONG_TIME ) ;

// wake up, not knowing that your "deadlock detector"
// has released your mutex

pSharedMem->mystuff++ ; // oh-oh... access to shared memory
                        // without the guarding mutex held.
                        // Who knows what will happen!

pSharedMem->m.release_lock() ; // you may very well trap or hit some
                             // system specific error because
                             // the mutex is no longer held.

（用get_lock() 和release_lock() 明确写出以明确突出锁定的范围）。

【讨论】：

没错，但是由于我们正在编写代码，我们知道每个进程不应持有超过几千个周期的锁。所以最好有一个监控进程来确保没有进程持有锁太久。
您是否正在运行实时调度保证？否则，（甚至可能）你不能总是控制为什么你被上下文切换并且在重新安排后没有再次给予 cpu 的原因。示例：由于突然不受监管的工作负载导致系统活动激增，导致系统 cpu 利用率接近容量，导致重新调度时间延迟很长。
好点，不，我没有运行任何类型的调度保证。尽管如此，是否无法区分持有锁的进程是简单地延迟还是被 SIGSEGV 杀死？