我的应用程序使用了许多关键部分，我想知道哪些可能会导致高争用。我想避免瓶颈，确保可扩展性，特别是在多核，多处理器系统上
当我在应用程序负载过重时等待进入临界区时发现许多线程悬空时，我已经意外地发现了一个。这很容易解决，但是如何在它们成为真正的问题之前检测到如此高的争用临界区？
我知道有一种方法可以创建一个完整的转储并从中获取信息（不知何故？）。但这是一种相当干扰的方式。应用程序是否可以动态执行此类问题的诊断？
我可以使用结构_RTL_CRITICAL_SECTION_DEBUG中的数据，但有一些注意事项表明这可能在不同的Windows版本中不安全：http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434648.aspx
有人可以建议一种可靠且不太复杂的方法来获取这些信息吗？
答案 0 :(得分：0)
除了关键部分（即信号量）之外，还有其他方法可以处理并发性。最好的方法之一是非阻塞同步。这意味着构建代码即使使用共享资源也不需要阻止。你应该阅读并发性的内容。此外，您可以在此处发布代码段，并且有人可以就如何改善您的合法代码提供建议。
答案 1 :(得分：0)
查看英特尔®线程档案器。它应该能够帮助发现这些问题。
此外，您可能希望通过将代码中的关键部分包装在磁盘上以便进行分析来检测代码。它实际上取决于应用程序本身，但它至少可以是线程等待CS的信息。
答案 2 :(得分：-1)
您所谈论的内容在测试过程中非常有意义，但在生产代码中并不可行。
我的意思是......你可以在生产代码中做一些事情，例如确定LockCount和RecursionCount值（这是记录的），从LockCount和presto中减去RecursionCount，你有＃个线程等待他们的手上CRITICAL_SECTION对象
你甚至可能想要更深入。 SDK中记录了RTL_CRITICAL_SECTION_DEBUG结构。关于这种结构，唯一改变的是一些保留字段被赋予名称并被使用。我的意思是..它在SDK标题（winnt.h）中，文档字段不会更改。你误解了雷蒙德的故事。 （他部分有过错，他喜欢和下一个人一样的感觉。）
我的一般观点是，如果您的申请中存在严重的锁定争用，您应该尽一切可能将其揪出来。但是如果你能避免它，就不要让关键部分内的代码更大。读取调试结构（甚至lockcount / recursioncount）只有在你持有对象时才会发生。它在调试/测试版本中很好，但它不应该投入生产。