C++多进程项目使用boost共享内存时find方法阻塞问题求助

问题根因分析 #

1. 共享内存段内部锁死锁
   boost的managed_shared_memory内部默认维护了一把互斥锁，用于保护段元数据（包括命名对象表、内存分配结构等）。当Reader进程在操作共享内存元数据的过程中崩溃（比如刚好在调用find、分配/释放共享内存、修改命名对象时），这把内部锁会处于永久持有状态，后续所有需要访问段元数据的操作（包括你调用的find方法）都会阻塞在获取这把锁的步骤，这是进程卡在find行的直接原因。

2. 非健壮进程间锁未处理异常退出
   你代码中用到的所有bip::named_mutex默认都没有启用健壮属性。如果进程在持有锁的阶段崩溃，锁的状态永远不会被重置，其他所有进程尝试获取该锁时都会永久阻塞。
   同时你的代码存在锁逻辑缺陷：Reader中对open_lock调用try_to_lock后，没有判断是否成功获取锁，未持有锁的情况下直接操作共享内存，会引发元数据并发修改，进一步提升锁死和结构损坏的概率。

3. 共享内存对象结构损坏
   你在共享内存中存储的boost::circular_buffer和bip::shared_ptr都属于非POD类型，其内部状态修改不是原子操作。如果进程在修改这些结构的过程中崩溃，会导致结构状态不一致，轻则触发异常，重则在访问时触发段内部的逻辑死锁。

解决方案 #

• 启用互斥锁的健壮属性：改用boost::interprocess::robust_mutex，Linux下底层会对应PTHREAD_MUTEX_ROBUST属性，当锁的持有者崩溃时，其他进程获取锁时会得到EOWNERDEAD错误，调用consume()方法即可重置锁状态。
• 禁用共享内存段内部锁：创建managed_shared_memory时传入最后一个参数为false关闭段内部的默认锁，改用你自己实现的外部健壮互斥锁保护所有段元数据操作，从根源避免内部锁死锁。
• 完善锁检查逻辑：所有try_to_lock操作必须判断返回结果，未成功获取锁的情况下禁止操作共享内存。
• 增加结构健康校验：每次打开共享内存段后，先校验circular_buffer等自定义结构的状态合法性，如果发现损坏，直接销毁旧的共享内存段重建，避免永久阻塞。
• 增加异常捕获逻辑：对所有读写共享内存结构的操作增加异常捕获，出现异常时优先释放所持有的锁，避免异常退出导致锁残留。

内容的提问来源于stack exchange，提问作者Shelly Bekhor