我正在尝试使用boost中的shared_lock和unique_lock库来实现资源上的基本读写器锁。但是，访问资源的一些线程可能会崩溃。我想创建另一个进程，给定一个互斥锁，监视互斥锁并跟踪锁定资源的进程以及每个进程有多长时间锁定。如果进程锁定超过给定的时间段，该进程还将强制进程释放其锁定。
尽管增强锁是所有范围的锁并且一旦超出范围就会自动解锁，但如果服务器崩溃，它仍然无法解决我的问题，从而将SIGSEGV发送到进程并将其终止。被杀死的进程不会调用任何析构函数，因此不会释放任何其持有的资源。
一个可能的解决方案是以某种方式在锁上放置一个计时器，以便在给定的锁定时间段之后强制进程释放锁定。虽然这违背了锁定的概念，但它适用于我们的情况，因为我们可以保证，如果任何进程持有锁定超过，比如说5分钟，那么可以很自然地说该进程被杀死或者有陷入僵局。
非常感谢有关如何解决此问题的任何建议！
由于“可能重复”，我之前的帖子已关闭，但所述重复的问题并未回答我的问题。
boost: how to monitor status of mutex and force release on deadlock
答案 0 :(得分：0)
不管这是否是个好主意，您可以使用共享内存来存储自己的互斥锁实现，以存储时间戳，进程标识符和线程标识符。
当线程想要锁定时，它需要在共享内存中找到一个空槽并使用原子测试和设置操作（如Windows上的InterlockedCompareExchange）来设置进程ID，如果当前值为空值。如果设置没有发生，则需要重新开始。在设置了进程id之后，线程将需要重复线程标识符的进程，然后对时间戳执行相同的操作（它不能只设置它，它仍然需要以原子方式完成）。
然后，线程需要检查所有其他已填充的插槽，以确定它是否具有最低的时间戳。如果不是，则需要记下具有最低时间戳的插槽，并轮询它，直到它被清空，具有更高的时间戳或已经超时。然后冲洗重复，直到线程具有最旧时间戳的槽，此时线程已获得锁定。
如果另一个插槽已经超时，则线程应该触发超时处理程序（可能会终止其他进程或只是在带有锁的线程中引发异常），然后使用原子测试和设置操作来清除插槽。 / p>
当带锁的线程解锁时，然后使用原子测试并设置操作来清除其插槽。
更新：还需要处理最低时间戳之间的关系以避免可能的死锁，并且处理它需要避免产生竞争条件。
答案 1 :(得分：0)
@Arno：我不同意软件需要如此强大以至于它不应该首先崩溃。容错系统（根据可用性的5个线来考虑）需要在面临关键过程的突然终止时进行检查。 pthread_mutexattr_*robust
保存所有者pid，互斥锁的最后一个使用时间戳应该有助于恢复。