10

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

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

编辑：这是我看到的评论示例（现在找不到它们）：

为了提升，这是废话。至少在窗户上。互斥锁不使用 WinAPI，而是创建自己的基于文件的实现（WinAPI = Kernel-Objects）。如果您的程序崩溃，文件将不会被删除。下次启动程序时，由于现有文件，无法创建互斥锁。

4

2 回答 2

10

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

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

无论如何，命名互斥体只是库提供的一小部分。更有用的特性之一是它为包括STL 分配器的共享内存区域提供了自己的内存管理器。我个人发现使用它提供的高级构造比使用原始内存更愉快。

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

此页面提供了有关库的实现和性能的更多详细信息，但不包括实现原理。

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

// 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 邮件列表（我在文档中找不到任何内容）。

于 2011-03-01T04:25:25.080 回答
3

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

于 2011-03-01T03:19:03.643 回答