Гонки (data races)
- Что это: два потока одновременно обращаются к одной переменной, по крайней мере один — на запись, без корректной синхронизации → поведение некорректно и непредсказуемо.
- Почему происходит: отсутствие атомарности и/или порядка выполнения; оптимизации компилятора/процессора могут менять порядок.
- Признак: онлайновые баги, воспроизводятся редко, зависят от планировщика.
- Профилактика и приёмы:
- Минимизировать разделяемое состояние: отдавать данные одному потоку (thread confinement) или делать объекты неизменяемыми (immutable).
- Использовать примитивы синхронизации: mutex/lock, synchronized, monitor, std::mutex, java.util.concurrent.
- Использовать атомарные операции для простых случаев: $\text{std::atomic<T>}$, $\text{AtomicInteger}$ — дают атомарность и видимость.
- Для сложных алгоритмов — lock-free структуры с CAS: использовать проверенные библиотеки.
- Правильно проектировать критические секции: держать их короткими, не захватывать блокировки внутри циклов.
- Отладка:
- Инструменты: ThreadSanitizer, Helgrind (Valgrind), Java Race Detector.
- Добавлять asserts и инварианты, стресс-тесты, воспроизведение под повышенной нагрузкой, ввод случайных задержек (fuzzing) для увеличения вероятности проявления гонок.
Дедлоки
- Что это: несколько потоков ждут друг друга бесконечно, образуя цикл ожидания ресурсов.
- Классический условие (Coffman): взаимное исключение, удержание и ожидание, отсутствие прерывания, циклическое ожидание.
- Профилактика и приёмы:
- Фиксированный порядок захвата замков (lock ordering). Если ресурсы упорядочены и все потоки берут их в одном порядке — циклы невозможны.
- Использовать try-lock + откат/повтор (спокойный backoff): если не удалось захватить все — освободить и попробовать снова с задержкой.
- Избегать вложенных длинных блокировок; дробить на более мелкие.
- Таймауты при ожидании (если возможно восстановление): избегают бесконечного блокирования.
- Высокоуровневые конструкции: транзакционная память, actor-модель, очереди сообщений, синхронизаторы (e.g. java.util.concurrent) часто избавляют от ручного управления множеством замков.
- Анализ зависимостей ресурсов и статическая проверка порядков захвата.
- Отладка:
- Логи стеков потоков (jstack, gdb) для обнаружения циклов ожидания.
- Инструменты детекции deadlock (ядро/VM часто умеет распознавать).
- Редукция и воспроизведение: упрощать сценарий до минимального набора ресурсов/потоков.
Видимость памяти и порядок операций
- Что это: запись, выполненная одним потоком, может быть не сразу видна другому из-за кэширования и переупорядочивания; нужно обеспечить нужные гарантии порядка и видимости.
- Формулировка (happens‑before): если действие $A$ «happens-before» действие $B$ (обозначим $A\stackrel{hb}{}B$), то все эффекты $A$ видимы в $B$.
- Примеры правил:
- Выпуск (release) и захват (acquire) блокировки создают $release\stackrel{hb}{}acquire$.
- В Java volatile-write $\stackrel{hb}{}$ volatile-read.
- В C++ атомарные операции с release/acquire дают аналогичные гарантии: store_{release} и load_{acquire}.
- Практические приёмы:
- Использовать атомарные типы и правильные memory-order (в C++/C11): $\text{memory\_order\_release}$, $\text{memory\_order\_acquire}$, $\text{memory\_order\_seq\_cst}$.
- В Java — $\text{volatile}$ для простых флагов или использовать synchronized/locks для комплексных инвариантов.
- Памятные барьеры (fences) при низкоуровневой оптимизации.
- Убедиться, что вся модификация состояния защищена одним и тем же механизмом синхронизации (lock/atomic/volatile), чтобы установить happens-before.
- Отладка:
- Ранние индикаторы: stale reads, наблюдаемое «пропадание» обновлений.
- Инструменты: ThreadSanitizer включает проверки релевантные visibility/race.
- Писать тесты с генерацией порядка операций, использовать моделирование памяти (инструменты для проверки памяти и формальное тестирование).
Практические рекомендации по хорошему дизайну
- Минимизировать разделяемую мутабельную глобальную информацию.
- Предпочитать высокоуровневые примитивы (конкурентные коллекции, каналы, actor).
- Применять явную политику владения ресурсами и порядок захвата.
- Делать критические секции короткими и документировать инварианты.
- Покрывать многопоточные части unit/integ тестами и использовать стресс/случайные сценарии.
- Использовать статический анализ и динамические санитайзеры (TSan, Helgrind), профилировщики для поиска узких мест и блокировок.
Короткие «чек‑листы» при отладке
- Воспроизведите проблему под нагрузкой / увеличьте количество потоков.
- Соберите дампы/стэки потоков при зависании.
- Включите детекторы гонок (TSan) и детектор deadlock’ов.
- Попробуйте упростить сценарий до минимального воспроизводимого примера.
- Протестируйте альтернативы: заменить lock на атомик, разделить ресурсы, ввести таймауты.
(Если надо — могу привести примеры кода для конкретного языка или набор команд для анализа с ThreadSanitizer/Helgrind/jstack.)