Краткий ответ

Нет. GIL не заменяет пользовательскую синхронизацию: он защищает внутреннее состояние интерпретатора CPython, но не делает составную операцию изменения общей переменной атомарной. Для корректного доступа нескольких потоков нужен, например, threading.Lock или другой подход, исключающий совместную запись.

Исторический контекст

GIL появился в CPython как относительно простой способ защитить внутренние структуры интерпретатора при выполнении Python-кода из нескольких потоков. В частности, он упрощает управление объектами и подсчётом ссылок, позволяя в каждый момент времени одному потоку исполнять байткод Python в данном процессе.

Это решение не предназначалось для защиты прикладных данных. Поэтому GIL ограничивает параллельное выполнение CPU-bound Python-кода, но не является универсальным механизмом согласования операций между потоками.

Постановка проблемы

Операция вроде увеличения общей переменной состоит не из одного неделимого действия: поток читает текущее значение, вычисляет новое и записывает результат. Между этими этапами другой поток может получить управление и прочитать то же исходное значение.

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

Подробное решение

GIL гарантирует, что одновременно байткод CPython исполняет только один поток. Однако поток может потерять GIL между отдельными инструкциями, а операции над пользовательскими объектами могут выполнять произвольный Python-код или временно освобождать GIL.

Для защиты составной последовательности действий используют threading.Lock. Блокировка должна охватывать весь критический участок — от чтения общего состояния до записи нового значения.

import threading

value = 0
lock = threading.Lock()

def increment():
    global value
    for _ in range(10000):
        with lock:
            value += 1

Здесь только один поток одновременно выполняет чтение и запись value. Цена решения — сериализация критической секции и возможное ожидание блокировки, поэтому её не следует удерживать во время длительных операций ввода-вывода или вычислений.

Альтернативы зависят от задачи: можно хранить состояние отдельно в каждом потоке и объединить результаты после работы, передавать данные через queue.Queue или использовать специализированные атомарные структуры. Выбор зависит от требуемой производительности, объёма общего состояния и необходимости сохранять порядок операций.

Ситуация из практики

Сервис запускает несколько потоков для обработки событий и увеличивает общий счётчик обработанных сообщений. Разработчик убирает блокировку, считая, что GIL исключает одновременное выполнение потоков.

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

Если счётчик нужен только для итоговой статистики, оптимальным решением будут локальные счётчики потоков с последующим объединением. Если значение должно точно обновляться и читаться во время работы, следует использовать Lock вокруг изменения и чтения; результатом будет корректная статистика с предсказуемой ценой синхронизации.

Что кандидаты часто упускают

Вопрос: Гарантирует ли threading.Lock, что защищённая переменная будет безопасна при чтении из другого места без этой блокировки?

Ответ: Нет. Защита работает только при соблюдении единого протокола: все чтения и записи, которые должны быть согласованы, выполняются под той же блокировкой. Если один поток пишет под Lock, а другой читает без него, приложение всё ещё имеет несогласованный доступ и может наблюдать промежуточное или логически устаревшее состояние.

Вопрос: Станет ли операция над общей переменной безопасной после замены обычного объекта на пользовательский класс с методом изменения?

Ответ: Само вынесение операции в метод ничего не гарантирует. Метод может состоять из нескольких действий, вызывать другой Python-код и взаимодействовать с общим состоянием. Без внутренней синхронизации такой метод не становится атомарным; блокировка должна быть частью его контракта или внутренней реализации.

Вопрос: Нужно ли использовать threading.Lock, если два потока работают с общей структурой только на чтение?

Ответ: Если структура действительно не изменяется после публикации, совместное чтение обычно не требует блокировки. Но при наличии параллельной записи ситуация меняется: чтение должно быть согласовано с записью, иначе можно получить логически неконсистентное состояние. Важно учитывать не только отдельные операции контейнера, но и составные сценарии вроде проверки условия с последующим изменением.