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