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

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

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

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

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


multithreading .net static-analysis c# ndepend
person Steve Dunn    schedule 04.03.2010    source источник

Ответы (6)


arrow_upward
20
arrow_downward

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

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

person Lasse V. Karlsen    schedule 04.03.2010
comment
Спасибо, Лассе, я слышал о ШАХМАТАХ, но не о TypeMock Racer. Я действительно искал инструмент для статического анализа кода. Я использую ReSharper 5, у которого есть замечательная функция, которая проверяет код, показывает всех вызывающих конкретный метод и рекурсивно просматривает их. Мне нужно что-то, что помечает метод как экземпляр, созданный в рабочем потоке. Я подробнее исследую подход CQL, поскольку я знаю, что существует сценарий вызывающих абонентов восходящего потока, поэтому я уверен, что есть способ узнать, являются ли какие-либо методы результатом вызова вызова потока. - person Steve Dunn; 04.03.2010
comment
Эта шахматная вилка, похоже, обновлена ​​и работает. - person zejuel; 22.02.2018

arrow_upward
4
arrow_downward

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

person John Gietzen    schedule 04.03.2010
comment
Хороший. Анализ времени выполнения намного превосходит статический анализ проблем параллелизма. Для статических анализаторов существует слишком много соглашений во время выполнения, чтобы обеспечить хорошее соотношение сигнал / шум. - person Michael Donohue; 04.03.2010
comment
похоже, Джинкс - тост. - person tofutim; 18.08.2016
comment
Википедия: Jinx был отладчиком параллелизма, который детерминированно контролирует чередование рабочих нагрузок между ядрами процессора, уделяя особое внимание взаимодействиям с общей памятью. Используя этот детерминированный подход, Jinx стремился увеличить частоту появления неуловимых ошибок общей памяти, иногда называемых Heisenbugs. Джинкс больше не доступен. Corensic, компания, которая разрабатывала Jinx, была куплена F5 Networks, и проект Jinx был отменен. - person tofutim; 18.08.2016

arrow_upward
4
arrow_downward

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

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

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

person Guillermo Ruffino    schedule 27.04.2015
comment
Это очень интересная идея. Вдохновленный вашим кодом, я написал нечто подобное, назначив номер приоритета каждой блокировке, а затем проверяя, что всякий раз, когда я получаю несколько блокировок, я получаю их в порядке приоритета. Разумеется, это сразу же показало, что в моей программе было одно место, где я нарушил собственное правило о порядке получения блокировок, и исправление этого устранило мою уязвимость в тупиковой ситуации. - person RenniePet; 16.09.2015
comment
Это выглядит проще, но эффективно! Не могли бы вы поделиться им на GitHub? Не забудьте проголосовать, если вы этого не сделали. Спасибо! - person Guillermo Ruffino; 16.09.2015

arrow_upward
3
arrow_downward

Возможно, вы захотите проверить ШАХМАТЫ.

person Kent Boogaart    schedule 04.03.2010

arrow_upward
2
arrow_downward

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

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

Также попробуйте FxCop. от Microsoft.

person David d C e Freitas    schedule 15.07.2011

arrow_upward
0
arrow_downward

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

  • Выявление узких мест в производительности за считанные минуты
  • Оптимизация производительности приложений .NET
  • Переход к медленным строкам кода с синхронизацией на уровне строки
  • Профилирование приложений aspx, ASP.NET, C # и VB.NET
person Keith Barrows    schedule 04.03.2010