Инструмент анализа C# / .NET для поиска условий гонки/тупиков

есть ли инструмент, который анализирует .NET-код и находит условия гонки?

У меня есть немного кода, который имеет публичное статическое свойство, которое получает или создает частную статического поля. Он также имеет открытый статический метод, который устанавливает для этого поля значение null (...да, я знаю!..)

поскольку ни один из этих методов не блокируется, можно с уверенностью сказать, что в будущем все пойдет ужасно неправильно. Мне нужен инструмент, который будет рекурсивно проходить через вещи, которые вызывают любой из них методы и посмотреть, если что-то было порождено в другом потоке.

Я ищу инструмент или, возможно, SQL-скрипт nDepend (если это возможно).

39
.net c# multithreading ndepend static-analysis

6 ответов

вы, вероятно, ищете один из них:

Примечание: этот ответ с 2010 года. Как и во всех ответах на рекомендации, рекомендации со временем меняются. Там могут быть и другие продукты, шахматы, которые были исследовательскими лабораториями Microsoft, возможно, превратились в конечный продукт или были полностью уничтожены. Пожалуйста, примите этот ответ с крупинкой соли и провести новые исследования, в которых продукты подходят сейчас.

19

Джинкс будет делать это во время выполнения (не статически), но, возможно, стоит посмотреть.

4

вы, возможно, захотите, чтобы проверить шахматы.

3

см. ответы здесь:какие инструменты статического анализа доступны для C#?

некоторые инструменты статического анализа могут выполнять обнаружение взаимоблокировки.

кроме того, попробовать FxCop из Microsoft.

2

я экспериментировал над тем, как легко отслеживать их. Я работал над отслеживанием некоторых тупиков, особенно в сценариях, где используется много разных операторов блокировки.

моя цель-обнаружить тупики до их возникновения, например, если у вас есть два ресурса, вы знаете, что всегда должны использовать их в том же порядке, иначе тупик может произойти.

lock (lockObj1) 
lock (lockObj2) 
{ 
    // some code
}

... где-то еще в приложении ...

lock (lockObj2) 
lock (lockObj1) // <- I expect some "possible deadlock" detection here 
{ 
    // some code
}

в этом случае я использую lockObj1 затем lockObj2 в одном месте и использовать их в обратном порядке в другом месте, это то, что вы хотели бы избежать в приложении Конечно, операторы блокировки не должны использоваться один за другим, как в Примере, ваше сложное приложение может иметь несколько сложных объектов, взаимодействующих друг с другом

Я загрузил код с тестовыми примерами здесь https://github.com/glmnet/LockTracer

2

вы смотрели Муравьи Красных Ворот? Я не уверен, что он сделает все, что вам нужно, но это хороший продукт для:

  • определить узкие места производительности в течение нескольких минут
  • оптимизация производительности приложений .NET
  • детализация до медленных строк кода с таймингами уровня строки
  • профиль aspx, ASP.NET, код C# и VB.NET приложения
0