Нельзя прямо указать конкретные состояния гонки без самого фрагмента кода; пришлите код — я найду их точно. Пока — общий набор типичных проблем с mutex/condition variable и конкретные тест‑сценарии, которые их выявляют.
Общие потенциальные состояния гонки и короткое объяснение
- Проверка предиката перед wait через `if` вместо цикла `while` → потеря/ложное пробуждение (spurious wakeup) и использование некорректного состояния.
- Сигнал (notify) посылается до того, как поток начал ждать → потеря сигнала (lost wakeup).
- Обновление состояния (флага/буфера) и сигнал в неправильном порядке: сигналуют до изменения состояния → ожидающий просыпается и видит старое состояние.
- Доступ к общей переменной без защиты mutex → классическая гонка/порча данных (data race).
- Уничтожение condition variable или mutex пока кто‑то ждёт → крах/UB.
- Непоследовательный порядок захвата нескольких mutex → взаимная блокировка (deadlock).
- Notify_one при нескольких ждущих и недостаточном количестве ресурсов → некоторые потоки навсегда останутся в ожидании.
- TOCTOU: проверка предиката вне mutex, затем wait — между проверкой и блокировкой состояние могло измениться.
- Неправильное использование спящих задержек/таймаутов (timed wait), игнорирование возвращаемого кода — ложные уверенности в успехе.
Тест‑сценарии, строго описанные (шаги и ожидаемое поведение)
1) Проверка `if` vs `while` (спurious wakeups / race на предикате)
- Настройка: один буфер размером $1$, один продюсер, два консьюмера. Код использует `if (!has_item) cond.wait(mutex);` (не `while`).
- Сценарий: продюсер кладёт элемент, делает `cond.notify_one()`; затем быстро кладёт ещё элемент и делает `cond.notify_one()` ещё раз;/или делать `cond.notify_all()` после нескольких операций.
- Поведение для выявления: если поток просыпается спурiously или многие потоки пробуждаются одновременно, один консьюмер может увидеть пустой буфер и использовать несуществующий элемент → assertion/крах. Решение: использовать `while (pred) wait`.
2) Сигнал раньше ожидания (lost wakeup)
- Настройка: один потребитель, один продюсер. Потребитель делает `cond.wait`, но в тесте мы инвертируем порядки: продюсер делает `cond.notify_one()` сразу после старта (до того как поток успеет войти в wait).
- Сценарий: заставить продюсера выполниться раньше (нет задержки), затем запустить потребителя; либо искусственно вставить `sleep` в потребителя.
- Ожидаемое: потребитель навсегда зависнет. Выявление: тест завершится с зависанием. Решение: использовать флаг/предикат и держать mutex вокруг проверки и изменения.
3) Сигнал до обновления состояния (ordering bug)
- Настройка: общий флаг `ready=false`. Тред A: `cond.notify_one()` затем `ready = true;` (ошибка порядка). Тред B: `wait` ожидает `ready == true`.
- Сценарий: запустить A и B с пересечением, или повторять $I$ раз: $I=$ $...$ — используйте большое число итераций, например $I=10000$.
- Ожидаемое: B может проснуться и увидеть `ready==false` (или никогда проснуться). Выявление: зависание или assert. Решение: сначала изменить состояние под mutex, затем notify.
4) Несколько потоков инкрементируют счётчик без mutex (data race)
- Настройка: общий счетчик `cnt = 0`; $T$ потоков, каждый делает по $N$ инкрементов без блокировки.
- Параметры: $T=8$, $N=100000$ (например).
- Сценарий: запустить и сравнить итоговый `cnt` с ожидаемым $T\times N$ ($=8\times 100000$).
- Ожидаемое: итог != ожидаемого (потерянные инкременты) или наблюдаются ошибки в инструментах (TSAN). Решение: защищать инкремент mutex или использовать атомики.
5) Deadlock из‑за разного порядка захвата mutex
- Настройка: два mutex `m1`, `m2`. Поток A захватывает `m1` затем `m2`; Поток B — наоборот.
- Сценарий: запустить A и B одновременно, возможно вставить небольшие `sleep` между захватами, повторить $I$ раз.
- Ожидаемое: иногда взаимная блокировка (оба заблокированы). Выявление: зависание/стек потоков. Решение: единый порядок захвата/try_lock + откат.
6) Уничтожение cond/mutex во время ожидания
- Настройка: поток B делает `cond.wait(mutex)` и блокируется. Главный поток через малое время делает `cond.destroy()` или выходит контекст создания.
- Сценарий: повторить с разными задержками.
- Ожидаемое: UB/крах. Выявление: стабильный крах при определённом interleaving. Решение: корректный жизненный цикл — join перед destroy.
7) notify_one при нескольких ожидающих и недостатке ресурсов (lost wakeups для некоторых)
- Настройка: N ресурсов положены продюсером, но он делает `notify_one()` только один раз; M>1 потребителей ждут.
- Сценарий: продюсер кладёт $k$ элементов, делает лишь одно notify. Повторить.
- Ожидаемое: часть потребителей останется в wait. Выявление: зависание. Решение: либо `notify_all()` при многократном наполнении, либо сигналить столько раз, сколько ресурсов.
8) TOCTOU: проверка предиката вне mutex
- Настройка: код делает `if (flag) { /* proceed */ } else { mutex.lock(); while (!flag) cond.wait(mutex); mutex.unlock(); }`
- Сценарий: другой поток меняет `flag` между проверкой и захватом mutex.
- Ожидаемое: пропуск уведомления/зависание. Выявление: нестабильные падения/зависания. Решение: всегда проверять предикат под mutex (atomic проверка тоже вариант).
Практические рекомендации по тестированию (инструменты и методика)
- Запускайте тесты многократно с рандомизацией и вставками `sleep/yield` в ключевых местах; число итераций $I$ сделайте большим, например $I=10000$.
- Используйте детекторы гонок: ThreadSanitizer (TSAN), Helgrind/DRD (Valgrind) — они найдут большинство data races.
- Пишете микро‑тесты, которые искусственно форсируют нужные interleavings: вставляйте `sleep(0)`/`sched_yield()`/`usleep()` и варьируйте задержки.
- Добавьте диагностические assert’ы/тайм‑аута в тест: если поток не проснулся за $S$ секунд (например $S=5$), тест считает это ошибкой и печатает стек потоков.
- Для проверки lost wakeup используйте разделение на «starter» и «waiter» с контрольными точками (barrier) и варьируйте порядок.
- Для deadlock используйте watchdog, граф захвата мьютексов (локи vs потоки) для диагностики.
Если пришлёте конкретный фрагмент псевдокода — я перечислю все места с риском состояния гонки и предложу минимальные тесты точно для вашего кода (с конкретными шагами и ожиданиями).