'managed_shared_memory' 应该分配多少内存？ （促进）

Question

我正在寻找一个明确的答案（如果确实存在的话），通过boost::interprocess 的managed_shared_memory 创建共享内存的静态块时应该分配多少内存。甚至official examples 似乎也分配了arbitrarily large 内存块。

考虑以下结构：

// Example: simple struct with two 4-byte fields
struct Point2D {
  int x, y;
};

我最初的反应是必要的大小是 8 个字节，或sizeof(Point2D)。当我尝试构造一个对象时，这会惨遭失败，在运行时给我段错误。

// BAD: 8 bytes is nowhere near enough memory allocated.
managed_shared_memory segment(create_only, "My shared memory", sizeof(Point2D));

什么读/写操作导致了段错误？堆栈操作？在segment.construct() 内临时分配？分配共享内存时需要多少开销？

通过反复试验，我发现将大小乘以 4 可以适用于上述结构，但是当我开始向我的 struct 添加更多字段时，它就崩溃了。所以，这听起来很糟糕。

有些人可能会争辩说现代 PC 中的“内存很便宜”，但我不同意这种理念，并且不喜欢分配超出我需要的内存，如果我可以避免的话。我昨天翻遍了 Boost 文档，找不到任何建议。今天要学点新东西！

Answer 1

来自文档的this paragraph：

内存算法是一个对象 被放置在一个的第一个字节 共享内存/内存映射文件 段。

内存段布局：

 ____________ __________ ____________________________________________  
|            |          |                                            | 
|   memory   | reserved |  The memory algorithm will return portions | 
| algorithm  |          |  of the rest of the segment.               | 
|____________|__________|____________________________________________| 

该库在段的开头有额外的内存开销，因此占用了您请求大小的几个字节。根据this post 和this post，无法确定这个确切的额外字节数：

你无法计算，因为有 是内存分配簿记和 碎片化问题的变化 运行时间取决于您的 分配/解除分配模式。和 共享内存按页分配 由操作系统（Linux 上的 4K 上的 64k windows），所以任何分配都将是 在实践中分配四舍五入到 页面：

    managed_shared_memory segment(create_only, "name", 20);

将浪费与以下相同的内存：

    managed_shared_memory segment(create_only, "name", 4096);

Answer 2

使用操作系统的内存页面大小之类的方法有效。就我而言，这是可行的..

off_t size = sizeof(class1) + (sizeof(class2) * 3);
// round up to the OS page size.
long page_size = sysconf(_SC_PAGE_SIZE);
size = ((size / page_size) + (size % page_size ? 1 : 0)) * page_size;

使用 boost::managed_shared_memory 允许您在结果空间中构造对象。有点像....

shared_memory_object::remove(m_name.c_str());
m_shared.reset(new managed_shared_memory(create_only, "myspace", size));
m_class1 = m_shared->construct<class1>("class1")();
m_class2 = m_shared->construct<class2>("class2")[3]();