问题标签 [boost-interprocess]

如果我使用allocate_aligned在一块共享内存中分配一个对齐的内存块，那么我如何在另一个进程中识别同一个块？例如

然后我如何ptr从另一个进程中找到？

对于我只是使用的非对齐分配find_or_construct，然后显然有一个与分配相关联的名称，这使得可以从另一个进程中找到分配。然而，似乎没有任何方法可以进行对齐分配，find_or_construct显然我必须错过一些关于如何识别匿名分配的基本点。

如果我使用allocate_aligned在托管共享内存中分配一块对齐的内存，是否保证此分配在其他进程中共享时具有相同的对齐方式？文档清楚地表明基地址的映射方式当然可能不同，但它似乎没有说明对齐。

我已经进行了一个实验，似乎表明对齐方式是相同的，但这可能只是运气好，所以我希望得到关于预期行为的更可靠的确认。（常识说它应该是相同的对齐方式，否则会严重限制allocate_aligned在共享内存中的有用性，但我真的需要的不仅仅是诉诸常识。）

我正在创建一个程序，该程序将从远程机器接收消息并需要将消息写入磁盘上的文件。我发现的困难在于这个程序的目的是测试接收消息的库的性能，因此，我需要确保将消息写入磁盘不会影响库的性能. 该库通过回调函数将消息传递给程序。另一个困难是解决方案必须独立于平台。

我有什么选择？

我想到了以下几点：

• 用于boost:asio写入文件，但似乎（请参阅此文档）异步写入文件位于该库的 Windows 特定部分中 - 因此无法使用。
• boost::interprocess用于创建消息队列，但本文档表明有 3 种方法可以发送消息，如果消息队列已满，所有方法都需要程序阻塞（隐式或不阻塞），我不能冒险。
• 创建一个std::deque<MESSAGES>从回调函数推送到双端队列，并在写入文件时弹出消息（在单独的线程上），但不保证 STL 容器是线程安全的。我可以锁定双端队列的推送和弹出，但我们谈论的是连续消息之间的 47 微秒，所以我想完全避免锁定。

有人对可能的解决方案有更多想法吗？

背景

该 文档说可以使库适应新的（不受支持的）操作系统。因为我想支持的操作系统（实时操作系统）接近 Win32，所以我希望很少有代码更改。我没有使用 Boost Thread 和 Boost Interprocess 的经验。

问题

• 如果不支持平台，你会推荐使用 Boost 的 Thread 和 Boost 的 Interprocess 吗？
• 有什么好处和坏处？
• 您会考虑哪些替代方案？

我正在开发一个到处使用boost::interprocess_mutexes 的项目，尽管该应用程序甚至从来没有fork()孩子，但严重依赖于多线程。

假设所有这些interprocess_mutexes 可以被进程本地互斥体替换而不破坏任何东西是否正确？

我认为这可能会提高性能（如果只是一个最小的因素）的假设是否正确？

在单个（可选多线程）进程中使用进程间同步是否有任何可以想象的理由？

我boost::interprocess::managed_shared_memory用于进程间通信。为了增长/缩小，共享内存必须在每个使用它的进程中取消映射。鉴于我有两个线程，这是如何完成的？

就我搜索boost文档而言，不存在类似 unmap/detach 函数的东西，所以也许我只需要删除指针？这行得通吗：（未经测试/未编译）

我也相信我必须使用一些观察者模式来使这个 100% 线程安全（参见源代码中的注释）。

我正在使用boost::interprocess::managed_shared_memory在不同进程之间共享一些数据，并且想知道清理是如何工作的。一般来说，我必须以下情况：

因为我调用 boost::interprocess::shared_memory_object::remove("TEST"); 我一直认为，无论如何，内存中的所有内容都会被删除，因此我不必照顾 sVec。但 Visual Leak Detector 告诉我，此时存在一些内存泄漏。如果我在删除共享内存之前清除向量，一切正常。是不是 sVec 在内部保存了指针，因此我必须调用 clear()？

我可以依赖在内存映射文件中分配的 boost multi_index_container 吗？这种“数据库”可以在具有相同字节序的计算机之间移植吗？

我有以下崩溃的代码。我怀疑这是因为分配了对我有这个问题的堆栈的引用。但我想避免每次都必须堆栈分配互斥锁和范围锁的成本

然后我存在该函数（cache_lock 是一个类字段），当尝试从不同的类方法中调用 cache_lock.lock 时，我的程序崩溃（在这种情况下 updateCache 在 cache_lock->lock() 部分崩溃）

我有两个问题：我怎样才能创建一个“持久的”cache_lock，这样我就可以在不调用named_mutex（open_only等）的情况下重用它？ak 我想避免每次都这样做

}

其次，重复上述过程（即找到互斥体并从中创建锁）是一项昂贵的操作？

boost::interprocess::message_queue 构造函数在进程在不同用户下运行时失败。
更具体一点。我在 proc1 中创建 message_queue。并尝试从 proc2（另一个用户）打开相同的 message_queue。
有可能让它工作吗？或者我应该找到另一种方法来同步我的流程？

boost-1.52
操作系统：Windows 7 x86
编译器：MSVC 2010

PS 代码很简单。如果两个进程都是从同一个用户启动的，则完全可以工作。

PPS 这是我收到的一个消息框。我无法调用 LastWindowError()...

我的代码（Process2）：

所以。我只收到“创建 mq”消息框。然后失败。

Boost 升级没有帮助。