我正在研究一个由内存映射文件支持的线程安全队列，该文件大量使用了 boost 进程间。我将它提交给代码审查，一位比我在这个星球上拥有更多年经验的开发人员说他不觉得 boost::interprocess 已经“准备好迎接黄金时间”，我应该直接使用 pthreads。
我认为这主要是FUD。我个人认为重新实现诸如 upgradable_named_mutex 或 boost::interprocess::deque 之类的东西是非常荒谬的，但我很想知道其他人的想法。我找不到任何数据来支持他的说法，但也许我只是不知情或幼稚。Stackoverflow 赐教！
我尝试将 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 本身中没有遇到任何不稳定或错误。我只是认为它的设计使您更难在您自己的代码中找到错误。
我们已经使用 boost::interprocess 共享内存和interprocess.synchronization_mechanisms.message_queue大约 6 个月了，发现代码可靠、稳定且相当易于使用。
我们将数据保存在相当简单的固定大小的结构中（尽管 12 个区域的大小总计 2+gb），并且我们按原样使用 boost::interprocess 示例代码并且几乎没有问题。
我们确实发现了在 windows 中使用 boost::interprocess 时需要注意的两点。
#include <boost/interprocess/shared_memory_object.hpp>对象，则只能通过首先重新启动 Windows 来增加内存映射区域的大小。这是因为 boost 如何使用文件后备存储。我并不是想说 Joseph Garvin 关于他的 boost::interprocess 问题的帖子是无效的。我认为我们的经验差异与使用图书馆的不同方面有关。我同意他的观点，在 boost::interprocess 中似乎没有任何稳定性问题。