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

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

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

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

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

Ответ 1

Возможно, вы ищете один из них:

ПРИМЕЧАНИЕ. Этот ответ с 2010 года. Как и во всех рекомендациях, рекомендации со временем меняются. Там могут быть и другие продукты, CHESS, который был проектом Microsoft Research Labs, возможно, превратился в конечный продукт или вообще был отменен. Пожалуйста, ответьте на этот вопрос с солью и проводите новые исследования, в которых продукты подходят сейчас.

Ответ 2

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

Ответ 3

Возможно, вы захотите проверить CHESS.

Ответ 4

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

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

Кроме того, попробуйте FxCop от Microsoft.

Ответ 5

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

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

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

Ответ 6

Вы посмотрели Red-Gate Ants? Я не уверен, что он сделает все, что вам нужно, но это хороший продукт:

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