GIL честно: что он сериализует, зачем он refcounting и что меняет free-threading в 3.13

Что GIL сериализует на самом деле

GIL — это один мьютекс на процесс внутри CPython: поток обязан держать его, чтобы исполнять байткод Python. Это всё правило целиком, и важны обе половины. Пока один поток крутит байткод цикла for, ни один другой не продвинется ни на одну инструкцию Python — поэтому 32 потока чистопайтоновского скоринга использовали одно ядро. Но блокировка отпускается ровно там, где об этом забывают: каждый блокирующий I/O-вызов стандартной библиотеки (socket.recv, file.read, time.sleep, драйверы БД) сбрасывает GIL перед уходом в ядро и забирает обратно после, так что 16 качающих потоков честно перекрывают свои ожидания. C-расширения умеют то же самое вокруг долгих вычислений: NumPy отпускает GIL внутри больших матричных операций, hashlib — при хешировании буферов больше 2 КБ, zlib и ssl — вокруг сжатия и хендшейков. Честная классификация — по нагрузке: чистопайтоновская CPU-работа в потоках не даёт ничего; I/O-тяжёлая в потоках — нормально; численная работа на C-расширениях в потоках может масштабироваться на удивление хорошо, потому что интерпретатор байткода — лишь один из жильцов вашего CPU.

import threading, time, hashlib

def pure_python(n=10_000_000):
    s = 0
    for i in range(n):       # привязан к байткоду: держит GIL всё время
        s += i
    return s

def c_extension(data=b"x" * 200_000_000):
    return hashlib.sha256(data).hexdigest()  # отпускает GIL во время хеширования

def timed(fn, threads):
    start = time.perf_counter()
    ts = [threading.Thread(target=fn) for _ in range(threads)]
    for t in ts: t.start()
    for t in ts: t.join()
    return time.perf_counter() - start

# Типичные результаты CPython 3.12 на 4 ядрах:
# pure_python  x1: ~0.45 с   x4 потока: ~1.9 с  (сериализация + накладные на переключение)
# c_extension  x1: ~0.55 с   x4 потока: ~0.7 с  (настоящий параллелизм в C)

Зачем он существует: refcounting не атомарен

CPython управляет памятью подсчётом ссылок: у каждого объекта есть счётчик, и почти каждый байткод его трогает — привязка имени инкрементирует, выход из области видимости декрементирует. Py_INCREF — это обычный ob->ob_refcnt++, операция «прочитать-изменить-записать», которая не атомарна. Два потока, инкрементирующие один счётчик, могут переплестись и потерять обновление; потерянный декремент — утечка объекта, потерянный инкремент — освобождение памяти, которая ещё используется, то есть use-after-free в ядре интерпретатора. Лобовые решения плохи: сделать каждую refcount-операцию атомарной инструкцией CPU исторически замедляло однопоточный Python примерно на 50% (Грег Стайн попробовал в 1999-м — патч отклонили ровно за это), а мелкозернистые блокировки на объект добавляют риск дедлоков и накладные расходы на самом горячем пути VM. Один глобальный замок сделал все refcount-операции безопасными бесплатно, сохранил скорость однопоточного кода и — критично — дал тысячам C-расширений простой контракт: пока твой код исполняется и ты не отпустил GIL, никакой другой поток ничего не мутирует. Именно этот контракт, а не ностальгия, растянул удаление на три десятилетия.

Пульс в 5 мс: как потоки сменяют друг друга

Внутри eval-цикла работающий поток проверяет флаг между байткодами; отдельный механизм запрашивает сброс каждые 5 миллисекунд по умолчанию — читается и настраивается через sys.getswitchinterval() / sys.setswitchinterval(). (До Python 3.2 это был счётчик байткодов через sys.setcheckinterval(100); временной дизайн его заменил.) Ловушка в том, что отпустить GIL — не то же самое, что честно его передать: кто проснётся первым, решает ОС, и на многоядерных машинах поток, только что отпустивший замок, часто немедленно забирает его обратно — он уже бежит на горячем ядре. Это и есть эффект конвоя из инцидента в начале: CPU-поток раз за разом обгоняет только что готовый I/O-поток, и healthcheck ждёт десятки или сотни миллисекунд своей очереди исполнить несколько байткодов. Уменьшение интервала (sys.setswitchinterval(0.001)) меняет throughput на латентность и остаётся пластырем; настоящее лечение — вообще не гонять CPU-bound работу на потоках интерпретатора: процессы (следующий урок) или free-threaded-сборка.

Free-threaded 3.13+: что меняет PEP 703 и сколько это стоит

Прежде чем катить 3.13t в прод в надежде на мгновенный CPU-параллелизм, стоит точно знать, что вы покупаете — и что это стоит до мержа PR деплоя.

Python 3.13 поставляется с экспериментальной free-threaded сборкой (python3.13t, собрана с --disable-gil): GIL отсутствует, и чистопайтоновские потоки масштабируются по ядрам. Машинерия на замену: biased reference counting (поток-владелец обновляет быстрый локальный счётчик, чужие потоки — атомарными операциями общий), бессмертные объекты (refcount у None, True, маленьких int никогда не меняется, синхронизация им не нужна), пообъектные блокировки для мутации контейнеров и mimalloc, делающий аллокацию потокобезопасной без глобального замка аллокатора. Честные цены, а не версия с кейноута: в 3.13 free-threaded-сборка исполняет однопоточный код примерно на 30–40% медленнее — в основном потому, что специализирующий адаптивный интерпретатор в этой сборке пришлось отключить; 3.14 включает его обратно и спускает накладные до единиц процентов, ближе к целевым 5–8% из PEP 703. Это отдельная сборка — дефолтный python3.13 из дистрибутива по-прежнему с GIL. И ловушка экосистемы: C-расширение обязано задекларировать поддержку free-threading (слот Py_mod_gil); импорт расширения без него молча включает GIL обратно в рантайме, печатая лишь RuntimeWarning. Команды выкатывали 3.13t, не видели масштабирования и пропускали, что одна транзитивная зависимость тихо вернула замок. Проверяйте python -c "import sys; print(sys._is_gil_enabled())" после импорта всего стека — и форсируйте через PYTHON_GIL=0 (тогда несовместимые расширения падают громко).