c++ - 使用单个编写器增长 Boost.Interprocess 内存映射文件

Question

我的问题是关于在单个写入进程和多个读取进程的上下文中使用 Boost.Interprocess 增加内存映射区域。 是否可以使用作者的 managed_mapped_file::grow，假设读者可以接受不更新 map 大小的变化？我的假设是读者的 map 将保持有效，然后当我需要读者从作者那里获取最新更改时，我可以使用更新后的大小重新映射读者。这是正确的吗？

Growing managed segments文档部分说:

Once a managed segment is created the managed segment can't be grown. The limitation is not easily solvable: every process attached to the managed segment would need to be stopped, notified of the new size, they would need to remap the managed segment and continue working. [...]

这让我觉得我可以成长，只要我对读者没有立即更新感到满意。但是，文档继续说:

On the other hand, Boost.Interprocess offers off-line segment growing. What does this mean? That the segment can be grown if no process has mapped the managed segment. If the application can find a moment where no process is attached it can grow or shrink to fit the managed segment. [...] managed_mapped_file also offers a similar function to grow or shrink_to_fit the managed file. Please, remember that no process should be modifying the file/shared memory while the growing/shrinking process is performed. Otherwise, the managed segment will be corrupted.

这让我觉得我不能做我想做的事，但我不明白为什么它行不通。

Answer 1

让我们仔细区分一下 shared_memory_object(这确实是低技术且没有影响力)和 managed_shared_memory/managed_mapped_file(两者都是使用 segment_manager)。

你正在使用后者。

---

"assuming it's acceptable for the readers not to be updated of the change of the map's size":

我不明白这个假设如何成立。

托管段本质上构成了一个辅助内存堆及其相关的控制结构。

控制结构包含诸如“堆”的实际范围之类的细节是有意义的。由于控制结构在共享内存中，因此它们也必须在已映射到读取进程的部分中。

更改内存段的大小会更改该控制结构中的值，该结构对于映射同一共享内存的所有进程都是可见的。这显然会对实际上没有足够的内存映射来满足新范围的进程造成严重破坏(最多导致页面错误)。

现在，我可以想象一个非常聪明的实现来规避对此类控制信息的需求(例如，带有标记值的经典空闲 block 列表)。但我不希望 Boost Interprocess 采取这条路线¹，并且您引用的文字强烈表明该设计不适合这种灵 active 。

Is it OK to use managed_mapped_file::grow from the writer, assuming it's acceptable for the readers not to be updated of the change of the map's size?

不，这不行。

My assumption is that the reader's maps would stay valid, and then I could remap the readers with the updated size when I need them to pick up the latest changes from the writer. Is this correct?

毫无疑问，/maps/会很好(取决于 grow 的实现方式，但我想我之前已经通过实验证实了这一点)。问题在于在顶部运行的 segment_manager。这是一个会被混淆的。

¹ 纯粹的 Fingerspitzengefühl