如何检测高争用临界区？

Question

我的应用程序使用了许多关键部分，我想知道它们中的哪些可能会导致高争用。我希望避免瓶颈，以确保可伸缩性，特别是在多核、多处理器系统上。

当我注意到许多线程在等待进入临界区时等待进入临界区时，当应用程序负载很重时，我已经意外发现了一个。这很容易修复，但如何在成为真正的问题之前检测到这种高争用的关键部分？

我知道有一种方法可以创建一个完整的转储并从中获取信息(不知何故？)。但这是一种相当侵入性的方式。对于这样的问题，应用程序有没有可以即时诊断自身的方法？

我可以使用structure Window中的数据，但需要注意的是，这在不同的_RTL_CRITICAL_SECTION_DEBUG版本之间可能是不安全的：http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434648.aspx

有人能建议一种可靠且不太复杂的方法来获取这样的信息吗？

Answer 1

您所讨论的内容在测试过程中非常有意义，但在生产代码中并不是真正可行的。

我是说..。您可以在生产代码中做一些事情，比如确定LockCount和RecursionCount的值(文档中有记录)，从LockCount中减去RecursionCount，然后快速完成，您就有了等待获得CRITICAL_SECTION对象的线程的数量。

你甚至可能想要更深一层。RTL_CRITICAL_SECTION_DEBUG结构在软件开发工具包中有说明。关于这种结构，唯一改变的是一些保留字段被命名并投入使用。我是说..。它在SDK头文件(winnt.h)中，文档中的字段不会改变。你误解了雷蒙德的故事。(他有部分过错，他和其他人一样喜欢轰动。)

我一般的观点是，如果您的应用程序中存在严重的锁争用，那么您应该通过各种方式将其找出来。但是，如果可以避免，千万不要让临界区中的代码变得更大。读取调试结构(甚至lockcount/递归计数)应该只有在你持有对象时才会发生。它在调试/测试版本中很好，但不应该投入生产。

Answer 2

除了临界区(即信号量)之外，还有其他方法来处理并发性。最好的方法之一是非阻塞同步。这意味着，即使在共享资源的情况下，也不需要阻塞代码。你应该读一读并发方面的知识。此外，您可以在此处发布代码片段，有人可以为您提供有关如何改进并发代码的建议。

Answer 3

查看英特尔线程档案器。它应该能够帮助发现这样的问题。

此外，您可能希望通过在代理中包装临界区来检测代码，该代理将数据转储到磁盘上以供分析。这真的取决于应用程序本身，但它可能至少是线程等待CS的时间信息。