Структура модуля (1–2 занятия): цель → короткая теория → 3 практических лабораторных задания → визуализации/эксперименты → выводы и вопросы для проверки понимания.
Краткие цели, которые должны усвоить ученики:
- понять, что такое гонка данных (data race) и почему результат непредсказуем;
- понять атомарность операций и какие примитивы её обеспечивают (атомарные операции, мьютексы, CAS);
- увидеть, как конкуренция за общий ресурс снижает производительность и почему.
1) Лаборатория A — простая гонка данных (демонстрация)
- Язык: Java/C++/Go (не Python из‑за GIL) или Web/JS с WebWorkers.
- Задача: N потоков по I увеличивают общий счётчик.
- Ожидаемое значение: $\text{expected}=N\times I$.
- Реализация 1 (без синхронизации): каждый поток делает read, increment, write.
- Что сделать:
- Запустить при $N=4,8,16$ и $I=100000$.
- Сравнить реальный итоговый счёт с $\text{expected}$.
- Ожидаемый эффект: итоговый счёт часто меньше $\text{expected}$ → объяснить потерю инкрементов как результат пересечения read/write.
- Визуализация: таймлайны потоков — для нескольких шагов показать перекрывающиеся операции: поток A прочитал 42, поток B тоже 42 → оба сохраняют 43 → один инкремент потерян. Нарисовать память (ячейка) и стрелки R/W.
2) Лаборатория B — атомарность и CAS
- Цель: показать, как атомарные примитивы устраняют гонки и как они работают.
- Задачи:
- Повторить лабораторию A, заменив несинхронизированный счётчик на:
1) мьютекс/lock вокруг инкремента;
2) атомарную операцию (Java AtomicInteger.incrementAndGet, C++ std::atomic::fetch_add или CAS loop).
- Демонстрация CAS (псевдокод):
- old = load(addr)
- new = old + 1
- if CAS(addr, old, new) success else retry
- Визуализация: показать атомарный RMW как «несрезаемую» коробку в таймлайне — никакие другие операции не могут попасть внутрь.
- Обсуждение: атомарные операции устраняют гонки корректно; но у CAS есть отказов/ретраев при сильной конкуренции.
3) Лаборатория C — контенция и потеря производительности
- Цель: измерить throughput и latency при увеличении числа потоков и длины критической секции.
- Эксперимент 1: общий счётчик под lock
- Внешняя работа (ненужная) = W вне lock; критическая секция длится C.
- Измерить время выполнения при разных N и фиксированном суммаре работ $T_{\text{total}}=N\times I$.
- Построить график throughput (операций в секунду) vs $N$.
- Ожидаемый профиль: сначала throughput растёт, затем насыщается и падает при высокой контенции.
- Эксперимент 2: сравнение атомарных операций и мьютексов
- Повторить замеры для атомика, мьютекса и несинхронизированной версии.
- Объяснить: атомики быстрее при короткой CS, мьютекс при длинной CS часто предпочтительнее.
- Эксперимент 3: false sharing
- Создать массив счётчиков, каждый поток обновляет свой элемент; без паддинга элементы попадают в одну кеш‑линию → резкое падение производительности.
- Добавить паддинг/выравнивание → производительность растёт.
- Метрики и формулы:
- Ожидаемое значение счётчика: $\text{expected}=N\times I$.
- Скорость/ускорение: $S(p)=\frac{T_1}{T_p}$.
- CPU‑utilization/throughput: измерять ops/sec и latency на операцию.
Визуализации (инструменты и идеи)
- Таймлайны (с полосами для каждого потока): операции R, W, CS (lock held) — цветами; видно пересечения и очереди.
- Sequence/trace view: список событий с временными метками и адресами памяти; подсветить конфликтующие R/W.
- Графики через Excel/Matplotlib: throughput vs threads, latency vs threads, процент успешных CAS vs threads.
- Псевдо‑машина памяти: показать состояние переменной в момент времени и стрелки от потоков.
- Интерактив: дать ученикам менять задержки (sleep) внутри/вне CS и смотреть как меняются графики.
Наглядные маленькие эксперименты для урока (5–15 минут каждый)
- «Инкремент без синхронизации»: запустить 10 раз при $N=8$, обсудить разброс результатов.
- «Добавь задержку» : вставить sleep(0) или small delay между read и write — увидеть увеличение числа пропущенных инкрементов.
- «Lock vs Atomic»: сравнить время выполнения при коротком и длинном CS.
- «False sharing demo»: два сценария — рядом в памяти и с паддингом — сравнить времена.
- «CAS contention»: создать горячую переменную и считать количество неудачных CAS (рестартов) при росте $N$.
Вопросы для проверки понимания
- Почему при несинхронизированном инкременте итоговый счёт часто меньше $\text{expected}$?
- Чем отличается атомарная операция от блокировки?
- Что такое false sharing и как его избежать?
- Почему увеличение количества потоков иногда снижает throughput?
Рекомендации по реализации в классе
- Использовать готовые шаблоны кода (малые файлы), чтобы ученики сосредоточились на запуске и наблюдениях.
- Предложить одноминутные задания «изменить N/CS и объяснить поведение» — быстро формируют интуицию.
- Предоставлять простой средства визуализации (рисунки на доске или интерактивный таймлайн), чтобы разбирать конкретные интерливинги операций.
- Обсуждать не только «как исправить» (замки/атомики), но и «когда не следует» — производительность vs корректность.
Краткие ожидаемые выводы для учеников
- Гонка данных — результат неконтролируемого interleaving: итог может быть непредсказуем.
- Атомарность гарантирует indivisible update; CAS — универсальный примитив, но под нагрузкой может ждать и тратить ресурсы.
- Контенция приводит к уменьшению параллелизма; оптимизация: уменьшать критические секции, минимизировать совместный доступ, избегать false sharing, применять подходящие примитивы (атомики для коротких RMW, мьютексы для сложных действий).
Если нужен, могу прислать готовые минимальные примеры кода для Java/C++/Go и шаблон для замеров.