and*_*iej 10 c++ windows shared-memory
我面临的情况是,我需要从一个进程到另一个进程传递数百兆字节的内存.现在我通过文件来做这件事太慢了.我想为了更快,这些文件应该直接写入RAM并可以从另一个进程访问.不需要花哨的同步.一个进程将创建共享内存对象并将其填充数据.另一个进程将读取并删除它们.但是我做了一个快速的研究,看起来你不能在Windows中的RAM中共享内存 - 共享内存由文件或页面文件支持.boost :: interprocess的文档证实了这一点.如果共享内存实现仍然使用磁盘,那么加速在哪里?有没有使用基于RAM的共享内存的C++库?
编辑:我进一步阅读:1.来自boost :: interprocess docs:"由于操作系统必须将文件内容与内存内容同步,因此内存映射文件不如共享内存快."2.来自http ://msdn.microsoft.com/en-us/library/ms810613.aspx:"内存映射文件也可以同时由多个应用程序映射.这代表了两个或多个进程直接共享数据的唯一机制在Windows NT中."
Mat*_*lia 15
我认为这是一个基本的误解:你认为,如果你创建一个由页面文件支持的文件映射,它将像在磁盘上实际写东西一样慢.
绝对不是这样的:文档中"由页面文件支持"的含义意味着共享内存通常驻留在内存中,但是如果没有足够的空闲,它在页面文件中有一个保留位置来写入这样的数据物理内存和虚拟内存管理器需要交换内存页面.
这在文档中并不是很清楚,但MSDN上的文件映射页确认:
[...]它由磁盘上的文件支持.这意味着当系统交换文件映射对象的页面时,对文件映射对象所做的任何更改都将写入该文件.当文件映射对象的页面被重新交换时,它们将从文件中恢复.
请注意,这适用于由页面文件支持的共享内存以及由常规文件支持的内存(VMM保证各种视图保持一致).
顺便提一下,这就是用户进程中"常规"(=虚拟)内存的工作原理:如果当前没有使用分配内存的每一位都可以交换到页面文件,系统需要使用物理内存来处理其他内容(例如制作您/其他应用程序可用的内存页面).
由文件支持没有任何问题- 在内存压力下,数据必须到达某个地方,您的选择是:
将内存视为无法分页或删除的神圣数据
可能只会产生更糟糕的内存压力问题,但对于一些可以很好地控制系统的整个运行时环境的嵌入式系统来说是个不错的选择.
放下记忆
显然不适合所有数据.缓存内容?也许.原始照片?可能不是.
将内存分页到磁盘
好的通用选择!
使用共享内存工具时,您是否看到内存压力?添加更多RAM或弄清楚如何缩小系统.:)
| 归档时间: |
|
| 查看次数: |
3844 次 |
| 最近记录: |