Question

我对跨平台IPC的默认选择会有所提升，但是我在两个不同的论坛上看到它被批评，当时我问到这个问题并且这让我很担心。也许这只是一个巧合，那么对于提升IPC和选择跨平台C ++ IPC库的想法有哪些？

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

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

对于提升，这是废话。至少在视窗。互斥锁不使用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文档中进行了更多挖掘，我遇到了各种有趣的tid位：

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。

推动IPC有什么好处吗？

2 个答案: