在没有文件支持的情况下保留共享内存(Linux/Windows) (boost::interprocess)



如何在没有文件支持的情况下保留和分配共享内存 ?我试图保留一个大(几十gb)的共享内存块,并将其作为IPC的一种形式在多个进程中使用。然而,大部分数据块根本不会被触及(访问将非常稀疏;也许在整个进程的生命周期中有几百兆字节),我不关心应用程序结束时的数据。

因此,最好的方法应该具有以下属性:

  1. 不提交整个范围。我将选择哪些部分提交(实际使用)(但模式是不可预测的。)
  2. 不需要内存映射文件或类似的东西。我不需要保存数据。
  3. 允许我从多个进程访问内存区域(我将显式地处理锁定)
  4. 可以在Linux和Windows上工作(显然需要64位操作系统)
  5. 实际使用共享内存。我需要表演
  6. (NEW)操作系统或库不尝试初始化保留区域(为零或其他)。这显然是不切实际和不必要的。

我一直在尝试使用boost::interprocess::shared_memory_object,但是这会导致在文件系统上创建一个大文件(与我映射的内存区域大小相同)。它确实会在之后删除文件,但这几乎没有帮助。

任何帮助/建议/指针/参考都是感激的。

注:我知道如何在Windows上使用本机API。POSIX似乎也有同样的功能(只是界面更简洁!)我正在寻找一种跨平台的方式。

UPDATE:我做了一些挖掘,结果发现我认为Windows中存在的支持只是内存映射文件的一个特殊情况,使用系统页面文件作为备份。(我以前从未注意到这一点,因为我在过去的项目中最多只使用了几兆字节的共享内存。)

另外,我现在有一个新的要求(上面的数字6)

在Windows上,所有内存都必须以某种方式由磁盘备份。

我认为你能在windows上完成的最接近的是内存映射一个稀疏文件。我认为这将在你的情况下工作,有两个原因:

  1. 在Windows上,只有您实际触摸的共享内存才会成为常驻内存。这符合第一个要求。
  2. 因为文件是稀疏的,所以只有修改过的部分才会实际存储在磁盘上。如果您查看文件的属性,它会显示类似于"大小:500 MB,磁盘大小:32 KB"。

我意识到这在技术上不符合你的第二个要求,但是,不幸的是,我认为这在Windows上是不可能的。至少使用这种方法,只有实际使用的区域才会占用空间。(只有当Windows决定将内存提交到磁盘时,它可能会或可能不会自行决定。)

至于把它变成一个跨平台的解决方案,一个选择是修改boost::interprocess,以便它在Windows上创建稀疏的文件。我相信boost::interprocess已经满足了您在Linux上的需求,其中POSIX共享内存是可用的。

最新更新