boost::interprocess 准备好迎接黄金时段了吗？ [关闭]

Posted 2023-02-21

【中文标题】boost::interprocess 准备好迎接黄金时段了吗？ [关闭]

【英文标题】：Is boost::interprocess ready for prime time? [closed]

【发布时间】：2010-07-07 15:40:42

【问题描述】：

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

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

【参考方案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> 类，其中SegmentPtr<0> 将是指向一个段的指针，SegmentPtr<1> 将是指向另一段的指针，等等，因此它们不能混淆（你只能这样做但如果你在编译时知道段数）。

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

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

【参考方案2】：

我们已经使用 boost::interprocess 共享内存和 interprocess.synchronization_mechanisms.message_queue 大约 6 个月了，发现代码可靠、稳定且相当易于使用。

我们将数据保存在相当简单的固定大小的结构中（尽管 12 个区域的大小总计 2+gb）并且我们按原样使用 boost::interprocess 示例代码并且几乎没有问题。

我们确实发现了在 windows 中使用 boost::interprocess 时需要注意的两点。

查看Boost Shared Memory & Windows。如果您使用默认的#include <boost/interprocess/shared_memory_object.hpp> 对象，那么您只能通过首先重新启动 Windows 来增加内存映射区域的大小。这是因为 boost 如何使用文件后备存储。 message_queue 类使用默认的 shared_memory_object。因此，如果需要增加消息大小，请再次重新启动 Windows。

我并不是说 Joseph Garvin 关于他的 boost::interprocess 问题的帖子无效。我认为我们的经验差异与使用图书馆的不同方面有关。我同意他的观点，在 boost::interprocess 中似乎没有任何稳定性问题。

【讨论】：

您的意思不是重新启动 Windows，而是重新启动应用程序？我在您的链接上没有看到任何有关重新启动 Windows 的信息，或者了解如何使用文件作为后备存储来实现必要的 O_o