C++中互斥锁和临界区之间的性能差异

我在阅读this post关于给定测试用例的临界区和互斥体之间的C＃性能差异。我在怀疑是否有任何进一步的文档给C++应用程序的各种锁定类提供性能开销，特别是在Windows 32或64位平台上运行的MFC？C++中互斥锁和临界区之间的性能差异

我问的原因是，我在广泛的自动化测试中得到的分析器结果显示在互斥代码中花费了大量时间。我试图弄清楚的是，在等待资源变得可用的时候，这是多少是合理的延迟，以及锁定结构的实现和具体情况。我只处理一个包含多个线程的进程，并且正在考虑更改为关键部分。长期自动化测试表明，我不需要互斥类提供的超时。

因此，这个问题是否有人知道任何有关不同Windows平台上不同MFC锁定机制的性能开销的参考文档？

来源

2011-10-10 Shane MacLaughlin

链接问题的答案也完全适用于MFC。因为像C＃一样，MFC类（如'CMutex'或'CCriticalSection'）只不过是相应的Win32功能的包装。 –

感谢Christian，我有点期待这一点，但想知道结果是语言依赖的，是否依赖硬件等等，以及是否有任何关于表现的硬性信息。根据Mark Ingram的回答，建议临界区域的MS文件只是“略快”而出现误导。 –

据我所知，一个Win32 Mutex是一个完整的内核对象。这意味着任何对互斥锁的调用都将涉及系统调用。这通常会使缓存无效，因此可能会非常昂贵。

关键部分是用户在没有争用的情况下不使用内核的对象。这可能是使用x86 LOCK汇编程序指令或类似的方法来保证原子性。由于没有进行系统调用，速度会更快，但由于它不是内核对象，因此无法从另一个进程访问关键部分。

来源

2011-10-10 12:24:34 doron

差不多。我认为通过“......从另一个线程”你实际上是指“......来自另一个进程”。 – RobH

感谢您的修复:) – doron

感谢您的信息。听起来就像我需要在各种平台和条件下自己运行一些测试。 –

Windows中关键部分和互斥体之间的关键区别在于，您可以创建一个命名互斥体并在多个进程中使用它，而无法从另一个进程访问一个进程的关键部分。

互斥锁在多个进程中可用的结果是对其的访问必须由内核控制。

来源

2011-10-10 12:32:16 RobH

请阅读以下Microsoft的支持文章：http://support.microsoft.com/kb/105678。

关键部分和互斥提供的同步非常相似，只是关键部分只能由单个进程的线程使用。当选择在单个过程中使用哪种方法时，需要考虑两个方面：

速度。在同步概述说以下有关关键部分：

...临界区对象提供了一个稍快，更高效的机制互斥同步。关键部分使用处理器特定的测试和设置指令来确定相互排斥的。

僵局。在同步概述说以下有关互斥：

如果一个线程终止不释放其互斥对象的所有权，该互斥体被认为是放弃。等待线程可以获取已放弃的互斥锁的所有权，但等待函数的返回值为表示该互斥锁被放弃。对于被放弃的互斥体，WaitForSingleObject（）将返回WAIT_ABANDONED。但是，互斥锁正在保护的资源是，处于未知状态。

无法判断关键部分是否已被放弃。

来源

2011-10-10 12:50:03

“稍快”这个词在这里让我感兴趣，因为迈克尔在相关帖子中的回答表明速度提高了20倍以上。 –

C++中互斥锁和临界区之间的性能差异

回答

相关问题