Способы найти состояние состязания
У меня есть немного кода с состоянием состязания в нем... Я знаю, что это - состояние состязания, потому что этого последовательно не происходит, и это, кажется, происходит чаще на двухъядерных машинах.
Этого никогда не происходит, когда я прослеживаю. Хотя, существует возможность, что это могла быть мертвая блокировка также. Путем анализа этапов завершения журналов, где это делает и не происходит, я смог точно определить эту ошибку к единственной функции. Однако я не знаю, где в пределах функции это происходит. Это не на верхнем уровне.
Добавление операторов журнала или точек останова собирается изменить синхронизацию, если это - состояние состязания, и предотвратите это.
Есть ли какая-либо техника, что я могу использовать кроме получения состояния состязания анализатор, который позволит мне точно определять, где это происходит?
Это находится в visual studio 9 с C++ (неуправляемого разнообразия).
6 ответов
Поместите спящие режимы в различные части вашего кода. Что-то, что является потокобезопасным, будет потокобезопасным, даже если оно (или асинхронный код) спит даже на несколько секунд.
Действительно, есть некоторые попытки автоматически найти условия гонки.
- Программа проверки гонок на основе Lockset
- Обнаружение гонок происходит до
- Обнаружение гибридных гонок
Еще один термин, который я прочитал в связи с обнаружением состояния гонки, - это RaceFuzzer, но мне не удалось найти действительно полезную информацию о нем. .
Я думаю, что это относительно молодая область исследований, поэтому, насколько мне известно, в основном есть теоретические статьи по этой теме. Однако попробуйте поискать в Google одно из приведенных выше ключевых слов, возможно, вы найдете полезную информацию.
Лучший способ отследить их, который я знаю, - это использовать ШАХМАТЫ в Visual Studio. Это непростой в использовании инструмент, который, вероятно, потребует постепенного тестирования подразделов вашего приложения. Удачи.
Итак, метод кувалды для меня заключался в следующем, который требует большого терпения и может в лучшем случае привести вас на верный путь. Я использовал это, чтобы выяснить, что происходит с этой конкретной проблемой. Я использовал точки трассировки, одну в начале предполагаемой высокоуровневой функции и одну в конце. Переместите точку трассировки вниз. Если добавление точки трассировки в начале функции приводит к тому, что ошибка перестает возникать, перемещайте точку трассировки вниз, пока вы снова не сможете воспроизвести условие. Идея состоит в том, что точка трассировки не повлияет на время, если вы поместите ее после вызова, который в конечном итоге приведет к срабатыванию небезопасного кода, но повлияет, если вы разместите ее раньше. Также обратите внимание на ваше окно вывода. Между какими сообщениями возникает ваша ошибка? Вы также можете использовать точки трассировки, чтобы сузить этот диапазон.
Как только вы сузите свою ошибку до управляемой области кода, вы можете добавить точки останова и посмотреть, что на данный момент делают другие потоки.
Это также может быть незащищенный ресурс, что может объяснить несогласованное поведение (особенно если на одном ядре работает нормально, а на двухъядерном нет). В любом случае проверка кода (как для условий гонки, так и для исходного кода, не являющегося потокобезопасным) может быть кратчайшим путем к решению.
Мне повезло с использованием точек трассировки Visual Studio для поиска условий гонки. Конечно, это все еще влияет на время, но в тех случаях, когда я его использовал, по крайней мере, этого было недостаточно, чтобы полностью предотвратить возникновение условий гонки. По крайней мере, это казалось менее разрушительным, чем специализированное ведение журнала.
Помимо этого, попробуйте опубликовать код, чтобы другие могли его просматривать. Простое детальное изучение кода - неплохой способ найти условия гонки.