如何检测高争用临界区？答案

【问题标题】：How to detect high contention critical sections?如何检测高争用临界区？
【发布时间】：2010-12-22 00:22:47
【问题描述】：

我的应用程序使用了许多关键部分，我想知道其中哪些可能会导致高争用。我想避免瓶颈，以确保可扩展性，尤其是在多核、多处理器系统上。
当我注意到在应用程序负载过重时等待进入临界区时有许多线程挂起时，我已经意外地发现了一个。这很容易解决，但是如何在它们成为真正的问题之前检测到如此高争用的关键部分呢？
我知道有一种方法可以创建一个完整的转储并从中获取该信息（不知何故？）。但这是一种相当侵入性的方式。是否有应用程序可以即时诊断此类问题的方法？
我可以使用结构 _RTL_CRITICAL_SECTION_DEBUG 中的数据，但有人指出，这在不同的 Windows 版本中可能是不安全的：http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434648.aspx
有人可以建议一种可靠且不太复杂的方法来获取此类信息吗？

【问题讨论】：

标签： winapi debugging

【解决方案1】：

您所说的内容在测试期间非常有意义，但在生产代码中并不真正可行。

我的意思是..您可以在生产代码中执行操作，例如确定 LockCount 和 RecursionCount 值（已记录在案），从 LockCount 中减去 RecursionCount，然后，您有 # 个线程等待处理 CRITICAL_SECTION对象。

您甚至可能想要更深入。 RTL_CRITICAL_SECTION_DEBUG 结构记录在 SDK 中。这个结构唯一改变的是一些保留字段被命名并被使用。我的意思是.. 它在 SDK 头文件 (winnt.h) 中，记录的字段不会改变。你误解了雷蒙德的故事。（他有部分过错，他和下一个人一样喜欢感觉。）

我的一般观点是，如果您的应用程序中存在严重的锁争用，您应该尽一切努力将其找出来。但是，如果可以避免的话，永远不要让关键部分中的代码变大。并且只有在您持有对象时才应该读取调试结构（甚至是锁定计数/递归计数）。在调试/测试版本中很好，但不应该投入生产。

【讨论】：

当然，这不是用于生产代码，这是调试的东西。我不是在寻求如何改进同步以避免争用的建议。我可以处理。我正在寻求帮助以确定需要优化的内容。我有几十个关键部分。其中一些很少使用，另一些可能会受到争用。我想对应用程序进行压力测试，看看哪些关键部分是瓶颈。因此，您说 RTL_CRITICAL_SECTION_DEBUG 已记录在案。你的意思是在 SDK 标头中吗？因为我在 MSDN 文档中找不到。
您能否确认 RTL_CRITICAL_SECTION_DEBUG.ContentionCount 从 Windows XP 到 Windows 7 的含义相同？
它在 SDK 头文件 (winnt.h) 中，并且定义不会根据目标版本集而改变。您可以放心使用它。
关于文档，全网都有解释这些领域的文章。
这个答案不正确。这个字段是内部的，虽然它在 winnt.h 中“记录”了——但这些字段不是您应该依赖的。我提醒您，因为在 Windows 8 中，这些字段会引发访问冲突。

【解决方案2】：

除了临界区（即信号量）之外，还有其他处理并发的方法。最好的方法之一是非阻塞同步。这意味着将您的代码结构化为即使使用共享资源也不需要阻塞。您应该阅读并发性。另外，您可以在此处发布代码 sn-p，有人可以就如何改进并发代码给您建议。

【讨论】：

【解决方案3】：

看看英特尔线程分析器。它应该能够帮助发现这些问题。

此外，您可能希望通过将关键部分包装在将数据转储到磁盘上进行分析的代理中来检测您的代码。这实际上取决于应用程序本身，但至少可以是线程等待 CS 多长时间的信息。

【讨论】：

线程分析器是强大的工具，但我需要一个轻量级的方法，而不需要检测整个代码。我想我会使用 RTL_CRITICAL_SECTION_DEBUG.ContentionCount。