🧵 Потоки и синхронизация

Короткий ответ threading.Lock — примитив синхронизации, гарантирующий, что в охраняемый блок кода в любой момент может войти только один поток, что превращает составную операцию в фактически атомарную относительно других потоков. Как это работает подробнее Lock.acquire() блокирует поток, если лок уже захвачен другим потоком, и пропускает его, если лок свободен; release() освобождает лок. Конструкция with lock: эквивалентна acquire()/release() с гарантированным release() даже при исключении. Пример кода Что использовать на практике Практика. Лок оборачивают вокруг минимально необходимого участка кода, читающего и изменяющего общие данные, чтобы не создавать лишних задержек для остальных потоков и не удерживать лок во время долгих операций. Подводные камни Риски. Оборачивают локом слишком большой участок кода, из-за чего многопоточность теряет смысл; забывают освободить лок вручную без with, что при исключении приводит к «зависшему» локу и дедлоку остальных потоков.

Читать полностьюconcurrency

Короткий ответ GIL — глобальный мьютекс в CPython, который позволяет только одному потоку выполнять байт-код Python в любой конкретный момент времени, даже если в процессе запущено несколько потоков. Как это работает подробнее GIL — особенность конкретной реализации CPython (а не языка Python), введённая для упрощения управления памятью (счётчики ссылок не потокобезопасны сами по себе). Потоки по очереди захватывают GIL, выполняя небольшие порции байт-кода, и периодически его отдают. Пример кода Что использовать на практике Практика. Для CPU-bound задач (чистые вычисления на Python) многопоточность в CPython не даёт параллельного ускорения. Для I/O-bound задач GIL освобождается на время блокирующей операции, поэтому потоки эффективно помогают перекрывать ожидания. Подводные камни Риски. Считают, что GIL автоматически делает любой код потокобезопасным — составная операция (x += 1) может быть прервана между чтением и записью; путают GIL с отсутствием параллелизма вообще, забывая про multiprocessing и C-расширен

Читать полностьюconcurrency

Короткий ответ Race condition — ситуация, когда результат программы зависит от непредсказуемого порядка выполнения нескольких потоков/процессов, обращающихся к общим данным без синхронизации, что приводит к неверным результатам. Как это работает подробнее Операция, выглядящая как одна строка (counter += 1), на уровне интерпретатора состоит из нескольких шагов (чтение, увеличение, запись); если два потока выполняют эти шаги «вперемешку», один из инкрементов может быть потерян, так как оба потока прочитали одно и то же старое значение. Пример кода Что использовать на практике Практика. Race condition легко возникает при работе с общими счётчиками, кэшами, списками из нескольких потоков без блокировок. Для диагностики помогает запуск большого числа повторений операции в нескольких потоках и сравнение итогового значения с ожидаемым. Подводные камни Риски. Считают, что GIL делает x += 1 атомарной операцией — GIL гарантирует атомарность отдельных байт-код инструкций, но составная операция может быть прервана между

Читать полностьюconcurrency

Короткий ответ Daemon-поток автоматически прерывается при завершении основной программы, не дожидаясь своего окончания, тогда как обычный поток удерживает процесс от завершения, пока сам не закончит работу — это удобно для фоновых задач, но рискует прервать работу без корректной очистки. Как это работает подробнее Атрибут daemon=True устанавливается до вызова start(); интерпретатор не ждёт завершения daemon-потоков при выходе из программы, в отличие от обычных потоков, которые нужно явно join() или программа будет ждать их завершения перед выходом. Пример кода Что использовать на практике Практика. Daemon-потоки удобны для фоновых служебных задач (периодическая очистка кэша, heartbeat), которые не критичны для корректности данных; для задач, критичных для целостности данных (запись в файл, коммит транзакции), daemon-поток рискован, так как может быть прерван посередине операции. Подводные камни Риски. Делают daemon-потоком задачу, которая должна гарантированно завершить запись данных перед выходом процесса, и

Читать полностьюconcurrency

Короткий ответ Нужно архитектурно свести к минимуму ситуации одновременного удержания нескольких локов, а там, где это невозможно, ввести единый документированный порядок захвата локов во всём коде и таймауты на acquire с логированием, чтобы потенциальный дедлок проявлялся как диагностируемая ошибка, а не бесконечное зависание. Как это работает подробнее Классический дедлок с несколькими локами требует одновременного удержания больше одного лока разными потоками в противоположном порядке; редкость и труднообъяснимость обычно означает, что условие возникает только при специфичной гонке по времени между путями кода, которые в обычных тестах не пересекаются достаточно часто. Компромисс. Полный отказ от нескольких одновременно удерживаемых локов устраняет риск дедлока почти полностью, но может создать излишнюю последовательность там, где логически возможен параллелизм, снижая throughput; введение таймаутов на acquire делает дедлоки наблюдаемыми и некатастрофическими, но требует продумать обработку отказа захвата

Читать полностьюconcurrency

Короткий ответ Поток создаётся через threading.Thread(target=функция, args=...), запускается методом start(), а join() блокирует текущий поток до завершения дочернего, что нужно для ожидания результата перед продолжением работы. Как это работает подробнее Thread.start() создаёт системный поток и запускает target-функцию параллельно основному потоку; без join() основная программа может продолжить выполнение, не дождавшись окончания работы дочернего потока. Пример кода Что использовать на практике Практика. join() используют, когда нужно гарантировать, что результат работы потока готов перед тем, как его читать, либо перед завершением программы, чтобы дочерние потоки успели корректно закончить работу. Подводные камни Риски. Забывают join() и обращаются к результату, который поток ещё не успел посчитать; вызывают join() с задачами, которые не завершаются, что приводит к зависанию основного потока без таймаута.

Читать полностьюconcurrency

Короткий ответ RLock (reentrant lock) позволяет одному и тому же потоку захватывать лок повторно без самоблокировки (счётчик захватов), тогда как обычный Lock заблокирует поток при попытке повторного захвата уже удержанного им же лока, что приведёт к дедлоку. Как это работает подробнее RLock хранит, какой поток владеет локом, и счётчик вложенных acquire(); release() нужно вызывать столько же раз, сколько было acquire(), прежде чем лок станет доступен другим потокам. Обычный Lock не знает про владельца — повторный вызов acquire() из того же потока блокируется. Пример кода Что использовать на практике Практика. RLock нужен, когда метод, уже держащий лок, вызывает другой метод того же объекта, который тоже пытается захватить тот же лок (рекурсивные или вложенные вызовы). Если такой вложенности нет, обычный Lock обычно достаточен и немного быстрее. Подводные камни Риски. Используют Lock там, где есть рекурсивные захваты того же лока одним потоком, получая неочевидный дедлок; используют RLock «на всякий случай» ве

Читать полностьюconcurrency

Короткий ответ Deadlock возникает, когда два потока захватывают несколько локов в разном порядке и каждый ждёт лок, уже удержанный другим — надёжное решение — всегда захватывать локи в едином, согласованном порядке во всём коде. Как это работает подробнее Поток A захватывает lock1 и ждёт lock2; поток B уже захватил lock2 и ждёт lock1 — оба блокируются навечно, так как ни один не может продолжить без лока, который держит другой. Пример кода Что использовать на практике Практика. Определяют глобальный порядок локов (например, по id объекта) и всегда захватывают их в этом порядке во всех местах кода; альтернативно используют acquire(timeout=...) и откат/повтор при неудаче, либо избегают удержания нескольких локов одновременно архитектурно. Подводные камни Риски. Захватывают локи в разном порядке в разных функциях, работающих с одними и теми же ресурсами (например, перевод между двумя счетами); не используют timeout на acquire, из-за чего дедлок невозможно детектировать программно — только по зависанию процесса.

Читать полностьюconcurrency