Гонки данных в Go

Что считается гонкой

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

Программа с гонкой считается некорректной, а поведение неопределённым. Это сильнее, чем «непредсказуемый порядок»: обещаний нет вообще никаких. Компилятор вправе поднять чтение done из цикла наружу, и тогда цикл повиснет навсегда. На моём прогоне не поднял. На другой версии, другой архитектуре или просто в другом окружении кода - поднимет, и никто не нарушит спецификацию.

// Один случай рантайм ловит специально: конкурентная запись в мапу печатает fatal error: concurrent map writes и убивает процесс. Я пробовал накрыть это через recover - не ловится, потому что это fatal error, а не паника.

гонка данных

несинхронизированный доступ, хотя бы один на запись

неопределённое поведение

никаких обещаний о результате программы

happens-before простыми словами

Модель памяти Go обещает видимость записи только там, где между записью и чтением установлен порядок. Устанавливают его пять вещей: мьютекс, операции с каналом, WaitGroup, sync.Once и atomic. Больше ничего. Ни sleep, ни «оно же на одном ядре», ни «переменная маленькая, запись атомарная».

Без этого порядка компилятор и процессор вправе переставлять и кэшировать операции. Поэтому флаг «работа закончена» через обычный bool - гонка, даже когда тесты зелёные, а замер показывает 23 миллиона успешных итераций. Правильно взять atomic.Bool или просто закрыть канал: закрытие канала видно всем получателям.

// Добавленный sleep гонку не чинит, а прячет. Расписание становится другим, конфликт перестаёт совпадать, а определение гонки продолжает выполняться слово в слово.

happens-before

порядок, который гарантирует видимость записи

переупорядочивание

право компилятора и процессора менять порядок операций

Детектор: что он видит и сколько стоит

Запустил тот же цикл под -race. Детектор напечатал WARNING: DATA RACE и два стека: запись в одной горутине, чтение в другой. Программа при этом снова отработала правильно. То есть по результату баг невидим, а детектор его показывает.

Работает он динамически: инструментирует реальные обращения и сообщает о конфликте, только если тот действительно случился в этом запуске. Непройденная ветка останется непроверенной, поэтому зелёный прогон с -race доказывает не отсутствие гонок, а лишь то, что в этот раз они не произошли.

// Про цену. В документации Go говорят о типичном замедлении около десяти раз. На моём микробенчмарке чистой блокировки вышло тридцать семь: 14,9 наносекунды превратились в 548,6, а у atomic 7,8 в 131,3. Микробенчмарк - худший случай, там кроме инструментируемых операций ничего и нет. Но вывод один: место -race в CI и на нагрузочном стенде, а не в проде.

-race

динамический детектор гонок, замедляет в разы

динамический анализ

видит только фактически случившиеся обращения

Как отвечать: «Что такое гонка данных и почему -race не гарантирует её отсутствие?»

Гонка данных это когда две горутины обращаются к одной переменной, хотя бы одно обращение на запись, и между ними нет синхронизации. Причём формулировка тут сильнее, чем «непредсказуемый порядок»: программа с гонкой считается некорректной, поведение неопределённое. Модель памяти Go гарантирует видимость записи только там, где установлено отношение happens-before, а создают его мьютекс, операции с каналом, WaitGroup, Once и atomic. Без этого компилятор и процессор вправе переставлять и кэшировать операции. Люблю показывать это на примере: цикл for !done с обычным bool у меня отработал нормально, вышел после двадцати трёх миллионов итераций, и по результату баг не виден вообще. Под -race тот же код сразу даёт WARNING: DATA RACE с двумя стеками. Правильно там взять atomic.Bool или закрытие канала. Теперь про детектор: он динамический, инструментирует реальные обращения и ловит конфликт, только если тот случился в этом запуске. Непройденная ветка или неудачно не совпавшее расписание - и гонка проходит мимо, поэтому зелёный прогон ничего не доказывает. Плюс он дорогой: на микробенчмарке блокировки я получил замедление в тридцать семь раз, в документации говорят про типичные десять. Отсюда и место: CI и нагрузочный стенд, не прод.

Сильный ответ: дано точное определение, объяснена модель памяти через happens-before с перечнем создающих его примитивов, показано на примере, что «работает» и «корректно» - разные вещи, и разобрана природа детектора вместе с ценой. Это уровень человека, который такие баги чинил.

На чём валят

• −Считают, что зелёный прогон с -race доказывает отсутствие гонок.
• −Синхронизируют флаг завершения обычным bool. У меня он отработал 23 миллиона раз и всё равно остался гонкой.
• −«Чинят» гонку добавлением sleep: она просто перестаёт совпадать.
• −Думают, что на одном ядре гонок не бывает. Переупорядочивание делает и компилятор тоже.
• −Пытаются перехватить concurrent map writes через recover. Это fatal error, recover мимо.