c++ - boost::interprocess 准备好迎接黄金时段了吗？

Question

很难说出这里问的是什么。这个问题是模棱两可的、模糊的、不完整的、过于宽泛的或修辞的，无法以目前的形式得到合理的回答。为了帮助澄清这个问题以便可以重新打开它， visit the help center .

关闭 9年前。

我正在研究一个由内存映射文件支持的线程安全队列，该文件大量使用了 boost 进程间。我将它提交给代码审查，一位比我在这个星球上拥有更多年经验的开发人员说他不觉得 boost::interprocess 已经“准备好迎接黄金时间”，我应该直接使用 pthreads。

我认为这主要是 FUD。我个人认为重新实现诸如 upgradable_named_mutex 或 boost::interprocess::deque 之类的东西是非常荒谬的，但我很想知道其他人的想法。我找不到任何数据来支持他的说法，但也许我只是不知情或幼稚。 Stackoverflow 赐教!

Answer 1

我尝试将 boost::interprocess 用于一个项目，但结果很复杂。我的主要疑虑是 boost::offset_ptr 的设计以及它如何处理 NULL 值——简而言之，boost::interprocess 可以使诊断 NULL 指针错误非常痛苦。问题是共享内存段映射到进程地址空间中间的某个位置，这意味着“NULL”offset_ptr 在取消引用时将指向有效的内存位置，因此您的应用程序不会 段错误。这意味着当您的应用程序最终崩溃时，可能会在错误发生很久之后，这使得调试变得非常棘手。

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

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

最后，offset_ptr 假设您将共享内存段中的指针存储到同一共享内存段中的其他点。如果您知道您将拥有多个共享内存段(我知道会是这种情况，因为对我而言，因为我有一个可写段和 1 个只读段)，它将彼此存储指针，offset_ptr 会妨碍您并且你必须做一堆手动转换。在我的共享内存库中，我制作了一个模板 SegmentPtr<i>所在类(class)SegmentPtr<0>将是指向一个段的指针，SegmentPtr<1>将是指向另一个段的指针，等等，这样它们就不会被混淆(你只能这样做，如果你知道编译时的段数)。

您需要权衡自己实现所有内容的成本与您将花费的额外调试时间来跟踪 NULL 错误并可能混淆指向不同段的指针(后者对您来说不一定是问题)。对我来说，自己实现东西是值得的，但我并没有大量使用 boost::interprocess 提供的数据结构，所以这显然是值得的。如果将来允许图书馆开源(不取决于我)，我会更新一个链接，但现在不要屏住呼吸；p

关于你的同事:我在 boost::interprocess 本身中没有遇到任何不稳定或错误。我只是认为它的设计让你更难在你自己的代码中找到错误。