boost :: interprocess_mutex vs Win32 native mutexes的性能是什么？

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

但是我问，因为也许有人已经做了这个比较，可以权威回答？

看起来在进程之间创build一个共享内存映射文件，通过使用InterlockedIncrement()来构build共享内存映射文件，可以创build一个类似于CRITICAL_SECTION的大部分的用户模式互斥体，这比用于进程间同步的Win32 Mutex性能要高得多。

所以我的期望是，可能是因为boost::interprocess_mutex在Win32上的实现已经以这种方式实现了，并且比原生API提供的要快得多。

创build一个安全的，转义的path基础/文件名，检查是否安全

问题在Windows 7上将boost log 1_60与MinGw链接起来

在Windows上将32位和64位的Boost构build到相同的文件夹中

Boost :: mutex比没有mutex的程序花费的时间less

提升精神：在Windows下断言失败，但不在Linux下。 为什么？

我只是有一个假设，我不知道通过现场testingboost::interprocess_mutex的性能是用于进程间同步还是深入研究它的实现。

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

在boost 1.39.0中，对pthreads只有特定的支持。 在所有其他平台上，它变成一个忙碌循环，中间有一个良率调用（基本上与您描述的系统相同）。 请参阅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是非常昂贵的 – 虽然无争议的情况几乎是免费的。 这可以通过添加一个事件对象或类似的睡眠来改善，但是这不适合boost :: interprocess的API，因为没有地方可以放置每个进程的HANDLE来访问互斥锁。

看起来在进程之间创建一个共享内存映射文件，通过使用InterlockedIncrement（）来构建共享内存映射文件，可以创建一个类似于CRITICAL_SECTION的大部分的用户模式互斥体，这比用于进程间同步的Win32 Mutex性能要高得多。

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

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

但是，正式的，你可以 。