推动IPC有什么好处吗？

Question

我对跨平台IPC的默认选择会有所提升,但是当我询问它时,我在两个不同的论坛上看到它受到批评,这让我很担心.也许这只是一个巧合,那么对于提升IPC和选择跨平台C++ IPC库的想法有何意义？

对于Windows dev,我们使用VC++ 2008作为参考.

编辑:这是我见过的评论示例(现在找不到它们):

对于提升,这是废话.至少在窗户上.互斥体不使用WinAPI,而是创建自己的基于文件的实现(WinAPI =内核对象).如果您的程序崩溃,则不会删除文件.下次启动Programm时,由于现有文件,无法创建互斥锁.

Answer 1

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

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

无论如何,命名的互斥体只是图书馆提供的一小部分.其中一个更有用的功能是它为包含STL分配器的共享内存区域提供了自己的内存管理器.我个人觉得使用原始内存提供的高级构造更令人愉快.

更新:我在Boost文档中做了更多挖掘,我遇到了各种有趣的tid位:

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

此链接明确指出其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邮件列表(我在文档中找不到任何内容).