我正在开发一个由内存映射文件支持的线程安全队列，该队列相当多地利用了Boost进程间。我提交了它进行代码审查，一位比我在这个星球上拥有更多年经验的开发人员说，他不认为 boost::interprocess 已经“准备好迎接黄金时间”，我应该直接使用 pthreads。
我认为这主要是FUD。我个人认为重新实现诸如 upgradable_named_mutex 或 boost::interprocess::deque 之类的东西是非常荒谬的，但我很想知道其他人的想法。我找不到任何数据来支持他的说法，但也许我只是不知情或天真。 Stackoverflow 启发我！
我尝试在一个项目中使用 boost::interprocess ，但感觉很复杂。我主要的疑虑是 boost::offset_ptr 的设计以及它如何处理 NULL 值——简而言之，boost::interprocess 会让诊断 NULL 指针错误变得非常痛苦。问题是共享内存段被映射到进程地址空间中间的某个位置，这意味着“NULL”offset_ptr 在取消引用时将指向有效的内存位置，因此您的应用程序won't段错误。这意味着当您的应用程序最终崩溃时，可能是在错误发生很久之后，这使得调试变得非常棘手。
但情况变得更糟。 boost:::interprocess 内部使用的互斥体和条件存储在段的开头。因此，如果您不小心写入 some_null_offset_ptr->some_member，您将开始覆盖 boost::interprocess 段的内部机制，并变得完全奇怪且难以理解的行为。编写协调多个进程并处理可能的竞争条件的代码本身就很困难，因此更加令人抓狂。
我最终编写了自己的最小共享内存库，并使用 POSIX mprotect 系统调用使我的共享内存段的第一页不可读且不可写，这使得 NULL bug 立即出现（你浪费了一页内存，但这么小的牺牲是值得的，除非您使用的是嵌入式系统）。您可以尝试使用 boost::interprocess 但仍然手动调用 mprotect，但这不起作用，因为 boost 会期望它可以写入它存储在段开头的内部信息。
最后，offset_ptr 假设您在共享内存段中存储指向同一共享内存段中其他点的指针。如果您知道您将拥有多个共享内存段（我知道会出现这种情况，因为对我来说，因为我有一个可写段和 1 个只读段），它们将相互存储指针，offset_ptr 会妨碍您并且您必须进行大量手动转换。在我的共享内存库中，我做了一个模板SegmentPtr<i>班级在哪里SegmentPtr<0>将是指向一个段的指针，SegmentPtr<1>将是指向另一个段等的指针，这样它们就不会混淆（但只有在编译时知道段数的情况下才能这样做）。
您需要权衡自己实现所有内容的成本与跟踪 NULL 错误以及可能混淆指向不同段的指针所花费的额外调试时间（后者对您来说不一定是问题）。对我来说，自己实现一些东西是值得的，但我没有大量使用 boost::interprocess 提供的数据结构，所以这显然是值得的。如果将来允许该库开源（不由我决定），我将使用链接进行更新，但现在不要屏住呼吸；p
不过，关于你的同事：我在 boost::interprocess 本身中没有遇到任何不稳定或错误。我只是认为它的设计让你更难在自己的代码中找到错误。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
