Boost IPC 好用吗？ [关闭]

Question

我对跨平台 IPC 的默认选择是 boost，但是当我询问它时，我看到它在两个不同的论坛中受到批评，这让我很担心。或许这只是一个巧合，那么对于 boost IPC 和选择跨平台的 C++ IPC 库，一般有什么想法呢？

对于 Windows 开发，我们使用 VC++ 2008 作为参考。

编辑：这是我见过的 cmets 示例（现在找不到它们）：

对于提升，这是废话。至少在 视窗。互斥体不使用 WinAPI， 相反，他们创造了自己的 基于文件的实现（WinAPI = 内核对象）。如果你的程序 崩溃文件不会被删除。 下次启动您的程序时 无法创建互斥锁，因为 现有文件。

Answer 1

根据我在 Boost.Interprocess 方面的有限经验，我没有遇到任何重大问题，但我无法对性能发表评论。虽然它确实使用在程序文件夹之外创建的文件来完成它的工作，但它们都应该是内存映射的，这可以消除大多数性能问题。在任何情况下，当您使用 IPC 时，您总是应该期待一些额外的性能开销。

至于您强调的​​批评，可以删除先前进程留下的命名互斥锁或任何其他命名资源（请参阅静态remove(const char*) 函数）。公平地说，根据您的应用程序，正确使用可能会很棘手，这不是您在使用 Windows API 时必须处理的事情。另一方面，Windows API 不可移植。我的猜测是他们使用文件（即使存在更好的替代方案）来保持库的界面和行为在不同平台上保持一致。

无论如何，命名互斥体只是库提供的一小部分。更有用的功能之一是它提供了own memory managers for the shared memory region，其中包括STL allocators。我个人觉得使用它提供的高级构造比使用原始内存更愉快。

---

更新：我在 Boost 文档中进行了更多挖掘，发现了各种有趣的花絮：

This page 提供了有关库的实现和性能的更多细节，但不包括实现原理。

This link 明确指出他们的 Windows 互斥锁实现可以使用一些工作（1.46 版）。如果您在boost\interprocess\sync 文件夹中进一步挖掘，您会注意到另外两个名为posix 和emulation 的文件夹。这两个都包含同步原语的实现细节。 interprocess_mutex::lock 的 posix 实现是您所期望的，但仿真实现非常基本：

// Taken from Boost 1.40.
inline void interprocess_mutex::lock(void)
{
   do{
      boost::uint32_t prev_s = detail::atomic_cas32(const_cast<boost::uint32_t*>(&m_s), 1, 0);

      if (m_s == 1 && prev_s == 0){
            break;
      }
      // relinquish current timeslice
      detail::thread_yield();
   }while (true);
}

因此，从表面上看，他们的目标是支持 Posix，并将其他所有内容都放入一个使用内存映射文件的仿真层中。如果您想知道他们为什么不提供专门的 Windows 实现，那么我建议您询问 Boost 邮件列表（我在文档中找不到任何内容）。

Answer 2

这不是对您问题的直接回答，而是另一种选择：如果您可以选择开发环境，那么您可以考虑 Qt 和the D-bus implementation in Qt。