GIL в Python: что блокирует и как обходят

Что именно она блокирует

Это один замок на весь интерпретатор. Чтобы выполнять байт-код Python, поток обязан его держать, поэтому в каждый момент код Python выполняет ровно один поток - сколько бы их ни было и сколько бы ни было ядер.

Но замок отпускается на время любой операции ожидания: чтение из сети, обращение к диску, сон. Отпускают его и многие библиотеки на C во время тяжёлых вычислений внутри себя. Именно поэтому мой замер дал два противоположных результата: счёт в два потока не ускорился вовсе (0,97 раза), а ожидание в четыре потока ускорилось почти вчетверо (3,99).

// Отсюда простое правило выбора. Ждёте - берите потоки или асинхронность, оба работают. Считаете - берите процессы, потому что у каждого процесса свой интерпретатор и свой замок. Считаете в библиотеке, которая внутри уходит в C и отпускает замок, - потоки тоже сработают, но это надо проверять, а не предполагать.

GIL

глобальная блокировка интерпретатора (global interpreter lock): код Python выполняет один поток за раз

отпускание на ожидании

во время сети, диска и сна замок свободен, и другой поток работает

Почему замок вообще существует

Он сильно упрощает внутреннее устройство интерпретатора: подсчёт ссылок на объекты и сборка мусора работают без отдельных замков на каждый объект. Плата - невозможность параллельного счёта в потоках; выигрыш - простота и скорость однопоточного кода.

Убрать его пытались много раз, и главная сложность не техническая, а совместимость: расширения на C рассчитывают на то, что замок есть. В последних версиях появился режим без глобальной блокировки, но пока он отдельный, экспериментальный, и за параллельность в нём платят замедлением однопоточной работы.

// На собесе это стоит проговорить именно так: замок никуда не делся, обходят его процессами или библиотеками, которые уходят в C. Обещать, что «в новой версии его убрали и всё стало параллельно», не надо - это будет неточно.

подсчёт ссылок

механизм учёта объектов; из-за него замок и упрощает интерпретатор

Как это выглядит в веб-сервисе

Обычный запрос к сервису - это на 90% ожидание: сходить в базу, дёрнуть чужой сервис, прочитать кэш. Такая нагрузка замком почти не ограничена, и один процесс с асинхронностью или с потоками держит сотни одновременных запросов.

Проблемы начинаются, когда внутри запроса появляется счёт: разбор большого документа, обработка изображения, сборка ответа на десятки мегабайт, шифрование. Такой запрос держит замок и тормозит ВСЕ остальные запросы этого процесса, даже те, что просто ждут базу.

// Лечится это тремя способами. Первый: несколько рабочих процессов на машине - тогда счёт в одном не мешает другим. Второй: тяжёлое выносят из запроса в фоновую очередь и отвечают пользователю сразу. Третий: конкретную тяжёлую операцию уводят в отдельный пул процессов. Обычно применяют все три сразу.

рабочие процессы

несколько процессов приложения на машине; у каждого свой замок

вынос в фон

тяжёлую работу делает отдельный обработчик, запрос отвечает сразу

Как отвечать: «Что такое GIL и почему потоки не ускоряют вычисления?»

GIL - это глобальная блокировка интерпретатора, один замок на весь интерпретатор: чтобы выполнять байт-код Python, поток обязан его держать, поэтому код выполняет ровно один поток за раз, сколько бы их ни было и сколько бы ядер ни стояло. Я это мерил: счётная задача в один поток занимает четыреста миллисекунд, а вдвое больше той же работы в двух потоках - восемьсот сорок, то есть ускорения нет вовсе. Но замок отпускается на время ожидания: сеть, диск, сон. Поэтому те же потоки на ожидании дали ускорение почти в четыре раза на четырёх потоках. Отсюда правило: ждёте - потоки или асинхронность, считаете - процессы, у каждого свой интерпретатор и свой замок. И третий случай: библиотеки, которые внутри уходят в C и отпускают замок, - там потоки на счёте тоже работают, но это надо проверять замером, а не предполагать.

Ответ даёт механику, два противоположных замера и правило выбора. Оговорка про библиотеки на C показывает, что человек различает случаи, а не заучил «GIL мешает всему».

На чём валятся

• −Разгоняют счётную задачу потоками и не получают ускорения.
• −Считают, что замок мешает всему, включая сеть и диск.
• −Обещают, что в новых версиях его убрали и всё стало параллельно.
• −Держат тяжёлый счёт внутри запроса и тормозят все остальные запросы процесса.
• −Забывают, что у каждого процесса свой замок, и не поднимают несколько рабочих процессов.