boost :: interprocess是否准备好黄金时间？

Question

我正在研究一个由内存映射文件支持的线程安全队列，这些文件相当大地利用了boost进程。我提交它用于代码审查，并且比我在这个星球上拥有更多年经验的开发人员表示他并不认为boost :: interprocess已经“准备好了黄金时间”，并且我应该直接使用pthread。

我认为这主要是FUD。我个人认为去重新实现诸如upgradable_named_mutex或boost :: interprocess :: deque之类的东西已经无稽之谈了，但我很想知道其他人的想法。我找不到任何数据来支持他的说法，但也许我只是不知情或天真。 Stackoverflow给我启发！

Answer 1

我试图对一个项目使用boost :: interprocess，并带着各种各样的感觉走开。我主要的担心是boost :: offset_ptr的设计，以及它如何处理NULL值 - 简而言之，boost :: interprocess可以诊断NULL指针错误真的很痛苦。问题是共享内存段被映射到进程地址空间中间的某个地方，这意味着“NULL”offset_ptr在取消引用时将指向有效的内存位置，因此您的应用程序将不会 segfault 。这意味着，当你的应用程序最终崩溃时，可能在错误发生后很长时间，使调试变得非常棘手。

但它变得更糟。 boost ::: interprocess内部使用的互斥和条件存储在段的开头。因此，如果您不小心写入some_null_offset_ptr-> some_member，您将开始覆盖boost :: interprocess段的内部机制，并且会变得非常奇怪且难以理解的行为。编写协调多个进程并处理可能的竞争条件的代码本身可能很艰难，所以它非常令人生气。

我最终编写了我自己的最小共享内存库，并使用POSIX mprotect系统调用使我的共享内存段的第一页不可读且不可写，这使得立即出现NULL错误（您浪费了一页内存，但是这样做除非你在嵌入式系统上，否则一个小牺牲是值得的）。您可以尝试使用boost :: interprocess，但仍然手动调用mprotect，但这样做不起作用，因为boost会期望它可以写入在段开始时存储的内部信息。

最后，offset_ptr的假设你正在将共享内存段中的指针存储到同一共享内存段中的其他点。如果你知道你将拥有多个共享内存段（我知道这是因为对我来说，因为我有一个可写段和一个只读段），它们将指针彼此存储，offset_ptr的方式和你必须做一堆手动转换。在我的共享内存库中，我制作了一个模板SegmentPtr<i>类，其中SegmentPtr<0>将指向一个段的指针，SegmentPtr<1>将指向另一个段的指针等，以便它们不会混淆（只有知道该数字时才可以这样做在编译时段）。

您需要权衡自己实现所有事情的成本，而不是额外的调试时间，您将花费追踪NULL错误并潜在地混合指向不同段的指针（后者对您而言不一定是问题）。对我来说，实现自己的东西是值得的，但我并没有大量使用boost :: interprocess提供的数据结构，所以显然值得。如果图书馆未来可以成为开源软件（不适合我），我会用链接更新，但现在不要屏住呼吸; p

对于你的同事，虽然：不会遇到boost :: interprocess本身的任何不稳定或错误。我只是觉得它的设计让你很难在自己的代码中发现错误。

Answer 2

我们一直在使用boost ::进程间共享内存和interprocess.synchronization_mechanisms.message_queue约6个月了，发现该代码是可靠的，稳定的，相当容易使用。

我们一直在我们的数据相当简单的固定大小结构的（虽然12个地区共计大小为2 + GB），我们使用了boost ::进程间示例代码是和几乎没有问题。

我们确实发现了两个项目要留意使用与Windows的boost ::进程间时。

1. 评论Boost Shared Memory & Windows。如果您使用默认#include <boost/interprocess/shared_memory_object.hpp>对象，那么你只能先重新启动的Windows增加了内存映射区域的大小。这是因为boost如何使用文件后备存储。
2. 的message_queue类使用默认shared_memory_object。所以如果消息大小需要增加，请重新启动Windows时间。

我不想说约瑟夫加文的帖子关于他与boost :: interprocess的问题是无效的。我认为我们的经验差异与使用图书馆的不同方面有关。我同意他的看法，在boost :: interprocess中似乎没有任何稳定性问题。