Средства обнаружения состояния гонки

Question

Я хотел бы протестировать большое и сложное (более 1,3 МЛ) серверное приложение для условий гонки. Приложение написано на C и C++ и работает на 64-битной Linux. Я провел некоторое исследование и придумал некоторые динамические инструменты (например, инспектор Intel, Tsan, Helgrind & DRD) и некоторые статические инструменты (например, RELAY, RacerX).

Динамические инструменты должны быть более точными (менее ложными срабатываниями) и могут обрабатывать пользовательские механизмы синхронизации, но накладывать значительные накладные расходы во время выполнения, которые будут вызывать таймауты приложения. Проблема со статическими инструментами заключается в том, что она, как правило, является академической и не поддерживается (например, последняя версия RELAY - с 2010 года).

В настоящее время я собираюсь использовать Tsan и растягивать таймеры приложения для размещения дополнительных накладных расходов. Кто-нибудь сталкивался с подобными проблемами и имел некоторые идеи, которые я, возможно, пропустил?

Answer 1

К сожалению, я думаю, что это может быть прошлой линией «мнений», но я сделаю снимок.

Не понимая ничего о приложении, почти невозможно сказать, что вам нужно учитывать при использовании Цзан. На меньшем (103k LOC) проекте, над которым я работаю, для работы с высокой пропускной способностью, почти всегда было достаточно для разработки тестов для реализации различных кодов кода и их проверки. Мне никогда не приходилось растягивать таймеры или таймауты. Я предполагаю, что это может быть проблематично, если у вас есть жесткие ограничения в реальном времени (я этого не делаю). Я не ощущал, что Цан накладные, чтобы быть непомерно большим.

Одна вещь, которую я должен отметить, это то, что Цзан не играет хорошо с параллельными структурами данных (такими как предоставленные concurrencykit и другими). Это связано с тем, что реализация этих параллельных структур данных часто зависит от обнаружения расчётов данных для определения поведения выполнения.

Рассмотрим, например, полный кольцевой буфер с двумя одновременными потребителями. Читатели, скорее всего, будут помечены как гоночные при временном прочтении передней части кольца, потому что они это делают. Тем не менее, потребители линеаризуют операцию атомного comare-and-swap, чтобы установить приращение, значение считывания с плавающей точкой для следующего индекса кольца. Если смена завершилась неудачно, операция повторится. Поэтому, хотя чтение и запись могут гоняться, правильность гарантирована.

С точки зрения Цзан, они не считаются ложными срабатываниями, поскольку они являются фактическими гонами данных. С другой стороны, они являются ложными срабатываниями для всех практических целей, поскольку они фактически не вызывают какого-либо неправильного или неопределенного поведения. Есть способы, которыми вы можете управлять своим кодом, чтобы избежать этого, но это было больше хлопот, чем того стоит, когда я его пробовал. Это зависит от того, насколько шумным является ваш выход.

Также обратите внимание, что если ваше приложение вызывается в неинструментарные библиотеки (libc, openssl, что угодно), вы пропустите потенциальные гонки. Если гонка происходит с одновременными вызовами в неинструментированную библиотеку, вы пропустите гонку.

При использовании Цан, не забудьте использовать -fno-omit-frame-pointer (и не забудьте установить, что после любой -Olevel опция). В противном случае вы попадете в ад с addr2line или будете вынуждены перестроить.

К сожалению, у меня нет опыта работы с другими утилитами, которые вы указали, но поскольку ваш вопрос, по-видимому, касается специфического Цзан, я надеюсь, что это будет полезно.