Question

请注意，我可以在增强源代码中进行研究，如果没有人在那里有答案，可以这样做来回答我自己的好奇心。

我确实要问，因为也许有人已经做过这种比较并且可以权威地回答？

似乎在进程之间创建共享内存映射文件，并且通过InterlockedIncrement()构造可以创建一个类似于CRITICAL_SECTION的用户模式互斥锁，这将比Win32更高效。用于进程间同步的互斥锁。

所以我的期望是，boost::interprocess_mutex的Win32上的实现可能已经以这种方式实现，并且它比原生API产品快得多。

我只有一个假设，我不知道通过现场测试boost::interprocess_mutex的性能来进行进程间同步，或深入研究它的实现。

有没有人有使用它或分析其相对性能的经验，或者他们是否可以评论在使用共享内存的进程中使用InterlockedIncrement（）的安全性？

Answer 1

在boost 1.39.0中，只有pthreads的特定支持。在所有其他平台上，它变成一个繁忙的循环，中间有一个yield调用（基本上与你描述的系统相同）。请参阅boost / interprocess / sync / emulation / interprocess_mutex.hpp。例如，这是lock（）的实现：

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);
}

这意味着Windows上的竞争boost :: interprocess :: mutex非常昂贵 - 尽管无竞争情况几乎是免费的。这可以通过添加一个事件对象或者类似于sleep on来改进，但是这不适合boost :: interprocess的API，因为无处可以放置访问互斥锁所需的每进程HANDLE。

Answer 2

似乎在进程之间创建共享内存映射文件，并且通过使用InterlockedIncrement（）进行构造，可以创建一个类似于CRITICAL_SECTION的用户模式互斥锁，这对于进程间同步来说比Win32 Mutex要高得多。 / p>

当存在争用时，

CRITICAL_SECTION内部可以使用同步原语。我忘记了它是一个事件，信号量还是互斥体。

你可以“安全地”在内存上使用Interlocked函数，所以你没有理由不能将它用于跨进程同步，除此之外真的很疯狂你应该使用线程或一个真正的同步原语。

But officially, you can

boost :: interprocess_mutex与Win32原生互斥锁的性能如何？

2 个答案: