是boost :: interprocess准备好黄金时间吗？ [英] Is boost::interprocess ready for prime time?

问题描述

我在一个线程安全队列支持的内存映射文件，它使用boost进程相当大。我提交了它的代码审查和开发人员比我在这个星球上更多的经验，说他不觉得boost :: interprocess是准备黄金时间，我应该只使用pthreads直接。

I was working on a thread safe queue backed by memory mapped files which utilized boost interprocess fairly heavily. I submitted it for code review and a developer with more years of experience than I have on this planet said he didn't feel that boost::interprocess was "ready for prime time" and that I should just use pthreads directly.

我认为这大多是FUD。我个人认为，重新实现诸如upgradable_named_mutex或boost :: interprocess :: deque之类的东西是可笑的，但我很想知道其他人的想法。我找不到任何数据来支持他的声明，但也许我只是不知情或天真。 Stackoverflow启发我！

I think that's mostly FUD. I personally think it's beyond ridiculous to go about reimplementing things such as upgradable_named_mutex or boost::interprocess::deque, but I'm curious to know what other people think. I couldn't find any data to back up his claim, but maybe I'm just uninformed or naive. Stackoverflow enlighten me!

推荐答案

我试图对项目使用boost :: interprocess，我的主要misgiving是boost :: offset_ptr的设计和它如何处理NULL值 - 总之，boost :: interprocess可以使诊断NULL指针的错误真的很痛苦。问题是共享内存段被映射到进程地址空间中间的某个地方，这意味着当被取消引用时，NULLoffset_ptr将指向有效的内存位置，因此您的应用程序不会 segfault。这意味着，当您的应用程序终于崩溃时，可能会在错误发生后很长时间，这使得调试非常棘手。

I attempted to use boost::interprocess for a project and came away with mixed feelings. My main misgiving is the design of boost::offset_ptr and how it handles NULL values -- in short, boost::interprocess can make diagnosing NULL pointers mistakes really painful. The issue is that a shared memory segment is mapped somewhere in the middle of the address space of your process, which means that "NULL" offset_ptr's, when dereferenced, will point to a valid memory location, so your application won't segfault. This means that when your application finally does crash it may be long after the mistake is made, making things very tricky to debug.

但它变得更糟。在内部增强:: ::进程间使用的互斥体和条件存储在段的开始。因此，如果你不小心写入some_null_offset_ptr-> some_member，你将开始覆盖boost :: interprocess段的内部机制，并得到完全怪异和难以理解的行为。编写代码来协调多个进程并处理可能的竞争条件可能会很困难，所以它是双倍疯狂。

But it gets worse. The mutexes and conditions that boost:::interprocess uses internally are stored at the beginning of the segment. So if you accidentally write to some_null_offset_ptr->some_member, you will start overwriting the internal machinery of the boost::interprocess segment and get totally weird and hard to understand behavior. Writing code that coordinates multiple processes and dealing with the possible race conditions can be tough on its own, so it was doubly maddening.

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

I ended up writing my own minimal shared memory library and using the POSIX mprotect system call to make the first page of my shared memory segments unreadable and unwritable, which made NULL bugs appear immediately (you waste a page of memory but such a small sacrifice is worth it unless you're on an embedded system). You could try using boost::interprocess but still manually calling mprotect, but that won't work because boost will expect it can write to that internal information it stores at the beginning of the segment.

最后，offset_ptr假设您将共享内存段中的指针存储到同一共享内存段中的其他点。如果你知道你将有多个共享内存段（我知道这将是这种情况，因为我有一个可写段和一个只读段），这将存储指针到另一个，offset_ptr的方式和你必须做一堆手动转换。在我的共享内存库中，我做了一个模板化的 SegmentPtr< i> 类，其中 SegmentPtr< 0> 段， SegmentPtr< 1> 将是指向另一个段等的指针，使得它们不能被混合（只有当你知道段的数量在编译时）。

Finally, offset_ptr's assume that you are storing pointers within a shared memory segment to other points in the same shared memory segment. If you know that you are going to have multiple shared memory segments (I knew this would be the case because for me because I had one writable segment and 1 read only segment) which will store pointers into one another, offset_ptr's get in your way and you have to do a bunch of manual conversions. In my shared memory library I made a templated SegmentPtr<i> class where SegmentPtr<0> would be pointers into one segment, SegmentPtr<1> would be pointers into another segment, etc. so that they could not be mixed up (you can only do this though if you know the number of segments at compile time).

你需要权衡实现自己的成本，而你需要额外的调试时间跟踪NULL错误和潜在的混合指针到不同的部分（后者不一定是你的问题）。对我来说，它是值得自己实现的东西，但我没有大量使用数据结构boost :: interprocess提供，所以它是显然值得的。如果图书馆今后允许开源（不是我），我会更新一个链接，但现在不能忍受你的呼吸; p

You need to weigh the cost of implementing everything yourself versus the extra debugging time you're going to spend tracking down NULL errors and potentially mixing up pointers to different segments (the latter isn't necessarily an issue for you). For me it was worth it to implement things myself, but I wasn't making heavy use of the data structures boost::interprocess provides, so it was clearly worth it. If the library is allowed to be open source in the future (not up to me) I'll update with a link but for now don't hold your breath ;p

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

In regards to your coworker though: I didn't experience any instability or bugs in boost::interprocess itself. I just think its design makes it harder to find bugs in your own code.

这篇关于是boost :: interprocess准备好黄金时间吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！