Как обнаружить критические участки с высокой конкуренцией?

Question

В моем приложении используется много критических разделов, и я хочу знать, какие из них могут вызвать высокую конкуренцию.Я хочу избежать узких мест, чтобы обеспечить масштабируемость, особенно в многоядерных и многопроцессорных системах.
Я уже обнаружил один случайно, когда заметил, что многие потоки зависали во время ожидания входа в критическую секцию, когда приложение находилось под большой нагрузкой.Это было довольно легко исправить, но как обнаружить такие критически важные разделы с высокой конкуренцией, прежде чем они станут настоящей проблемой?
Я знаю, что есть способ создать полный дамп и получить из него эту информацию (каким-то образом?).Но это довольно навязчивый способ.Существуют ли методы, которые приложение может сделать на лету, чтобы диагностировать себя для таких проблем?
Я мог бы использовать данные из структуры _RTL_CRITICAL_SECTION_DEBUG, но есть примечания, что это может быть небезопасно в разных версиях Windows: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434648.aspx
Может кто-то предложитьнадежный и не слишком сложный способ получить такую ​​информацию?

Answer 1

Посмотрите на Intel Thread Profiler. Это должно помочь выявить такие проблемы.

Также вы можете использовать свой код, оборачивая критические секции в прокси, который сбрасывает данные на диск для анализа. Это действительно зависит от самого приложения, но это может быть как минимум информация о том, как долго поток ждал CS.

Answer 2

То, о чем вы говорите, имеет смысл во время тестирования, но не реально выполнимо в производственном коде.

Я имею в виду ... вы МОЖЕТЕ делать что-то в производственном коде, например, определять значения LockCount и RecursionCount (это задокументировано), вычитать RecursionCount из LockCount и presto, у вас есть число потоков, ожидающих, чтобы попасть в CRITICAL_SECTION объект.

Возможно, вы даже захотите пойти глубже. Структура RTL_CRITICAL_SECTION_DEBUG задокументирована в SDK. Единственное, что когда-либо изменилось в отношении этой структуры, - это то, что некоторым зарезервированным полям были присвоены имена и они были использованы. Я имею в виду ... это в заголовках SDK (winnt.h), документированные поля НЕ меняются. Вы неправильно поняли историю Рэймонда. (Он частично виноват, ему нравится ощущение так же, как и следующему парню.)

Мой общий смысл: если в вашем приложении есть серьезная конкуренция за блокировку, вы должны, конечно, вывести это из себя. Но никогда не делайте код внутри критического раздела больше, если вы можете избежать этого. А чтение структуры отладки (или даже lockcount / recursioncount) должно происходить только тогда, когда вы держите объект. Это нормально в отладочной / тестовой версии, но не должно запускаться в производство.

Answer 3

Есть и другие способы управления параллелизмом, кроме критических секций (например, семафоров).Одним из лучших способов является неблокирующая синхронизация.Это означает, что структурирование вашего кода не требует блокировки даже с общими ресурсами.Вы должны прочитать о параллелизме.Кроме того, вы можете опубликовать фрагмент кода здесь, и кто-то может дать вам совет о том, как улучшить код параллелизма.