Growing Boost.Interprocess內存映射文件與單個寫入器

Question

我的問題是關於使用Boost.Interprocess，在單個寫入器進程和多個讀取器進程的上下文中增加內存映射區域。 使用作者的managed_mapped_file::grow是否可以，假設讀者不需要更新地圖尺寸的更改是可以接受的？我的假設是，讀者的地圖將保持有效，然後當我需要他們從作者處獲取最新更改時，我可以用更新的大小重新映射讀者。它是否正確？

文檔的Growing managed segments部分表示：

一旦管理的段中創建管理的段不能生長。這個限制並不容易解決：每個連接到被管理部分的進程都需要停止，並通知新的大小，他們需要重新映射被管理部分並繼續工作。 [...]

這讓我覺得我可以grow只要我很好，讀者不馬上更新。然而，文件繼續說：

另一方面，Boost.Interprocess提供離線分段增長。這是什麼意思？如果沒有進程映射受管段，則可以擴展段。如果應用程序可以找到一個沒有附加進程的時刻，它可以增長或縮小以適應被管理的細分市場。 managed_mapped_file也提供了類似的功能來增長或管理文件。請記住，在執行增長/縮小過程時，不應該修改文件/共享內存。否則，被管段將被損壞。

這讓我覺得我不能做我想做的事，但我不明白爲什麼它不起作用。

Answer 1

讓我們shared_memory_object之間的區別小心（這實在是低技術含量和未施加）和managed_shared_memory/managed_mapped_file（兩者使用segment_manager）。

您正在使用後者。

---

「假設它是可以接受的讀者不要地圖的大小的變化的更新」：

我不認爲這個假設是如何成立。

管理的段本質上構成了輔助內​​存堆及其關聯的控制結構。

控制結構包含諸如「堆」的實際範圍等細節是有意義的。由於控制結構位於共享內存中，因此它們必須位於已經映射到讀取進程中的部分。

更改內存段的大小會更改該控制結構中的值，該值可從映射相同共享內存的所有進程中看到。這顯然會在實際上沒有足夠的內存映射以滿足新擴展（導致頁面錯誤，最好）的進程中造成嚴重破壞。

現在，I 可以想象一個非常智能的實現，它避免了對這種控制信息的需求（例如像一個帶有標記值的經典空閒塊列表）。但我不認爲Boost Interprocess已經採用了這種路線¹，並且您引用的文字強烈暗示該設計不適合這種靈活性。

可以使用作者的managed_mapped_file :: grow，假設讀者可以接受不更新地圖大小的更改嗎？

不，它不好。

我的假設是，讀者的地圖將保持有效，然後當我需要他們從作者處獲取最新更改時，我可以用更新的大小重新映射讀者。它是否正確？

毫無疑問，/ maps /會很好（取決於grow的實現方式，但我認爲我已經通過實驗證實了這一點）。問題在於頂部運行的segment_manager。這是一個會被混淆的人。

¹純Fingerspitzengefühl