Есть ли инструмент, который анализирует код .NET и находит условия гонки?
У меня есть немного кода, который имеет общедоступное статическое свойство, которое получает или создает личное статическое поле. Он также имеет открытый статический метод, который устанавливает это поле в значение null (... да, я знаю!..)
Поскольку нет никаких блокировок вокруг любого из этих методов, это безопасная ставка, что в будущем все будет ужасно ошибочно. Мне нужен инструмент, который будет рекурсивно проходить через вещи, которые называют один из этих методов, и посмотреть, было ли что-то создано в другом потоке.
Я ищу инструмент или, возможно, nDepend SQL script (если это возможно).
Возможно, вы ищете один из них:
ПРИМЕЧАНИЕ. Этот ответ с 2010 года. Как и во всех рекомендациях, рекомендации со временем меняются. Там могут быть и другие продукты, CHESS, который был проектом Microsoft Research Labs, возможно, превратился в конечный продукт или вообще был отменен. Пожалуйста, ответьте на этот вопрос с солью и проводите новые исследования, в которых продукты подходят сейчас.
Jinx будет делать это во время выполнения (не статически), но, возможно, стоит посмотреть.
Возможно, вы захотите проверить CHESS.
См. ответы здесь: Какие средства статического анализа доступны для С#?
Некоторые инструменты статического анализа могут выполнять обнаружение блокировки.
Кроме того, попробуйте FxCop от Microsoft.
Я экспериментировал, как легко отследить их. Я работал над отслеживанием некоторых взаимоблокировок, особенно по сценариям, в которых используется множество различных операторов блокировки.
Моя цель - обнаружить взаимоблокировки до того, как они произойдут, например. если у вас есть два ресурса, вы знаете, что вы всегда должны использовать их в одном порядке, иначе может возникнуть взаимоблокировка.
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
Вы посмотрели Red-Gate Ants? Я не уверен, что он сделает все, что вам нужно, но это хороший продукт: