在 managed_shared_memory 中提升进程间互斥锁答案

【问题标题】：boost interprocess mutex in managed_shared_memory在 managed_shared_memory 中提升进程间互斥锁
【发布时间】：2013-08-09 09:14:27
【问题描述】：

我在进程 1 中有一个线程创建 boost::interprocess::managed_shared_memory 段。在这一部分中，我使用自定义分配器分配了一个 boost::interprocess::deque，并使用默认分配器创建了一个 boost::interprocess::interprocess_mutex 和 2 个 boost::interprocess::interprocess_condition 变量。我使用 find_or_construct 方法来创建这些。

我有另一个进程（进程 2），它使用我在进程 2 中打开的 boost::interprocess::managed_shared_memory 段上的 find 方法打开这些。

我了解 managed_shared_memory 段具有内核或文件系统持久性，而 interprocess_mutex/interprocess_condition 变量具有进程级持久性。

我被卡住的场景。

1) 进程 1 启动创建所有内容的线程。

2) 进程 2 启动并打开所有内容，此时共享内存和同步运行良好。

3) 进程 1 重新启动试图再次创建所有内容的线程（我相信它不应该，因为我正在使用 find_or_construct）

4) 进程 2 在等待调用条件变量时卡住了，即使进程 1 中的线程已经完成了通知。

在如何创建共享内存和互斥体/条件或持久性方面，我是否遗漏了一些东西？我在 Windows 上运行此代码。

【问题讨论】：

标签： c++ multithreading boost ipc sync

【解决方案1】：

考虑使用：

boost::interprocess::named_mutex
boost::interprocess::scoped_lock<boost::interprocess::named_mutex>
boost::interprocess::named_condition

而不是在现有共享内存块中分配互斥锁和条件变量。 Boost 为您处理了很多杂乱的细节。

注意：您在进程空间中创建这些 named_* 对象，而不是在共享内存中。 Boost 会为您创建包含互斥体和条件变量的实际共享内存段。

我在尝试将共享内存段两次映射到同一个进程时也遇到了麻烦。当您运行试图创建新映射的 Process1 线程的第二个实例时，是否有可能在旧映射仍然存在时？

【讨论】：

我不确定它是否正在尝试创建新的映射，我不这么认为，因为我认为它会尝试打开现有的映射。有没有办法检查？最初我曾尝试使用 then named_mutex 和 named_condition 变量，但遇到了条件变量问题，我将其发布在 stackoverflow 上但没有得到答案 stackoverflow.com/questions/17731050/…。
我看了你的另一个问题，一旦我理解了它（对于嘈杂的 cmets 感到抱歉，但我在编译运行时在后台执行此操作，所以我在第一次阅读时错过了一些东西。 ) 我同意那里的代码是正确的（除非您创建/销毁互斥锁和共享内存段，但不是条件变量）
嗨 Dale，我不确定静态包装器的作用。不过我的理解是，在线程开始或退出时调用的 remove 方法应该只在没有任何连接的情况下删除东西，对吗？
我使用了 named_mutex 来保护 shared_memory 区域的构造。（未管理，我自己分配内存）在那个区域我分配了一个对象，其中包含 boost::interprocess::interprocess_mutex 和 boost::interprocess::interprocess_condition。使用 boost::interprocess::scoped_Lock<...> 来锁定/解锁它。这行得通。一个区别...
作为一般规则，我总是尝试在通知条件之前解锁互斥锁。这避免了休眠进程唤醒并尝试重新获取互斥锁但失败的情况，因为通知进程仍然拥有互斥锁。（即，它经常通过调度程序减少一次行程。）