parallel-programming/lab05_sync/методичка.md

Лабораторная работа 5. Синхронизация и гонки данных

Время на работу: 2 пары. Зависимости: лабы 2, 4.

Цель работы

Увидеть гонку данных своими глазами (без синхронизации результат «плавает»), научиться защищать общие ресурсы (Lock, Semaphore, Event) и собрать классическую схему producer–consumer без дедлоков.

Теория

Гонка данных

Гонка — ситуация, когда результат зависит от порядка доступа потоков к общим данным. Классика: counter += 1 — это три операции (прочитать, увеличить, записать). Два потока могут прочитать одно значение, оба увеличить, оба записать — одно из двух увеличений потеряется.

Важно: x += 1 в Python не атомарен. Атомарны отдельные операции вроде list.append (спорно, но под GIL обычно надёжно) — полагаться на это нельзя.

Инструменты синхронизации

Инструмент	Что делает	Когда нужен
Lock	взаимное исключение: только один в критической секции	защита счётчиков, списков
RLock	Lock, который можно взять повторно тем же потоком	рекурсивные функции
Semaphore(n)	разрешает не более n одновременных входов	лимит на соединения/ресурс
Event	флаг «событие произошло»: set() / wait()	сигнал между потоками
Condition	ожидание условия (wait/notify)	сложные очереди
Barrier(n)	все ждут, пока соберутся n	синхронный старт

В multiprocessing те же примитивы есть в multiprocessing (они работают между процессами через разделяемую память ОС).

Producer–consumer

Классическая схема: производители кладут задачи в очередь, потребители забирают. queue.Queue — потокобезопасна сама по себе (внутри Lock + Condition). Главные грабли:

• Дедлок: потребитель ждёт get(), а производитель уже закончил. Решение: «маркер конца» (put(None)) — по одному на каждого потребителя, или get(timeout=...)/get_nowait().
• Забытый join очереди или потоков — программа завершается раньше времени.

Как искать гонки

• Замеры не помогут — гонка «мимикрирует». Помогает:
  1. увеличение числа потоков и повторов;
  2. time.sleep(0) внутри критической секции — усиливает переключения;
  3. сравнение результата с эталоном (checksum).

Задание

Заполните solution.py:

1. race_demo(n_threads, n_increments) — n потоков увеличивают общий счётчик n_increments раз каждый БЕЗ синхронизации. Вернуть (фактический_счётчик, ожидаемый). Фактический должен быть МЕНЬШЕ ожидаемого хотя бы иногда — если всегда ровно, увеличьте параметры и повторите (см. «Как искать гонки»).
2. race_fixed(n_threads, n_increments) — то же с threading.Lock. Результат обязан быть точным всегда. Замерьте, во что обходится Lock.
3. semaphore_limiter(items, delay, max_concurrent) — выполнить items «запросов» io_fetch на потоках, но не более max_concurrent одновременно (Semaphore + ThreadPoolExecutor). Вернуть (результаты, сек).
4. producer_consumer(n_producers, n_consumers, n_items) — производители кладут n_items задач суммарно, потребители обрабатывают, программа завершается без дедлока. Вернуть количество обработанных задач.
5. main() — демонстрация всех пункто�� с замерами.

Ожидаемые результаты

• race_demo: счётчик < ожидаемого (часто сильно); при больших n_increments потери растут.
• race_fixed: всегда ровно; время чуть больше (цена Lock).
• semaphore_limiter: время ≈ items / max_concurrent × delay — лимит работает.
• producer_consumer: обработано ровно n_items, завершается сам.

Контрольные вопросы

1. Почему counter += 1 не атомарен? Какие операции он включает?
2. Чем Semaphore(3) отличается от трёх Lock? Где это полезно?
3. Что такое дедлок и как «маркер конца» его предотвращает?
4. Почему queue.Queue не требует внешнего Lock?
5. Приведите пример из вашей CPU-задачи, где нужна синхронизация при многопоточности (например, сборка результатов).

Что сдаётся

solution.py + отчёт: вывод race_demo (несколько запусков!), сравнение race_fixed, замеры semaphore_limiter, описание схемы producer–consumer, ответы на вопросы.

Критерии оценки

Пункт	Баллы
race_demo демонстрирует потери (или обоснование, почему не демонстрирует)	2
race_fixed даёт точный результат всегда	2
semaphore_limiter: лимит соблюдается, замеры есть	2
producer–consumer завершается сам, ничего не теряется	2
Отчёт и ответы на вопросы	2

Типичные ошибки

• race_demo всегда даёт точный результат → увеличьте n_increments (10⁵+), число потоков, добавьте time.sleep(0) после чтения счётчика.
• producer–consumer висит → забыли маркеры конца или не join() потоки.
• Lock взят внутри with другого Lock в другом порядке → дедлок (порядок взятия замков должен быть единым).