我有一个托管共享内存段，它有一个 boost::interprocess::interprocess_mutex 和一个 boost::interprocess::interprocess_condition 变量。我有 2 个进程访问共享内存，它们正在根据互斥锁和条件同步访问。我遇到了一个案例，我的第一个进程阻塞了 notify_all 方法，最初我认为这是一个非阻塞方法，但似乎进程间条件实现了一个互斥锁，用于同步自身。
我遇到这种死锁的情况是进程 2 在等待条件时被不正常地杀死，我相信这会阻止条件互斥锁被解锁，然后当我再次运行进程 2 时它会阻塞。我第二次启动进程 2 时是否需要重置或清理进程间条件。
【问题讨论】：
标签： c++ boost ipc mutex shared-memory
http://www.boost.org/doc/libs/1_48_0/boost/interprocess/sync/interprocess_mutex.hpp
你在使用定时锁吗？
对于简单的死锁避免算法，请看这里：Wikipedia
它用于线程，但我相信它可以与 interprocess_locks 一起使用。
递归地，只允许一个线程通过锁。 如果其他线程进入锁，它们必须等到初始线程 通过完成 n 次。但如果数量 进入锁定的线程等于被锁定的数量，分配 一个线程作为超线程，并且只允许它运行（跟踪 它进入/退出锁定的次数）直到它完成。 一个超线程结束后，条件变回使用递归锁的逻辑，退出超线程
将自己设置为不是超线程
通知locker其他被锁定、等待的线程需要重新检查这个条件
如果存在死锁场景，则设置一个新的超级线程并遵循该逻辑。否则，恢复常规锁定。
请注意，上述算法无法解决 livelock 情况，为防止此类行为，请尽可能使用semaphore。
我惊讶地发现 interprocess_mutex 不支持实现死锁避免算法，因为这些天，大多数互斥体，即 std::mutex 和 boost::mutex 已经支持。
我猜这是操作系统特定的限制。
要获得更大的灵活性，请尝试使用named_upgradable_mutex
使用定时锁在进程崩溃时捕获异常并删除可升级的互斥锁！。此类型还允许任一线程获得提升权限！
【讨论】：