Python (мфа: [ˈpʌɪθ(ə)n]; в русском языке встречаются названия пито́н[23] или па́йтон

Глобальная блокировка интерпретатора (GIL)

Интерпретатор Python в CPython (а также Stackless и PyPy^[147]) использует потоко-небезопасные данные, во избежание разрушения которых при совместной модификации из разных потоков применяется глобальная блокировка интерпретатора — GIL (Global Interpreter Lock)^[148]: в ходе исполнения кода поток интерпретатора блокирует GIL, выполняет в течение фиксированного времени (по умолчанию 5 миллисекунд^{[К 2]}) некоторое количество инструкций, после чего освобождает блокировку и приостанавливается, давая возможность работать другим потокам. GIL также освобождается во время ввода-вывода, изменения и проверки состояния синхронизирующих примитивов, при исполнении кода расширений, не обращающихся к данным интерпретатора, например, NumPy/SciPy. Таким образом, в каждый момент времени в одном процессе интерпретатора Python может исполняться только один поток кода на Python, независимо от числа доступных процессорных ядер.
Потери производительности от GIL зависят от характера программ и архитектуры системы. Большинство программ является однопоточными, либо запускает всего несколько потоков, из которых часть в каждый конкретный момент простаивает в ожидании. Персональные компьютеры обычно имеют небольшое количество процессорных ядер, которые загружены параллельно исполняющимися в системе процессами, так что реальные потери производительности на персональных компьютерах из-за GIL невелики. Но в серверных приложениях может быть удобно использовать десятки и сотни (а то и больше) параллельных потоков (например, в системах массового обслуживания, где каждый поток обрабатывает данные для отдельного пользовательского запроса), а серверы на конец 2010-х годов нередко имеют десятки и даже сотни процессорных ядер, то есть технически могут обеспечить этим потокам физически одновременное исполнение; в таких условиях GIL может приводить к действительно значительному снижению общей производительности, так как лишает программу возможности полноценно использовать ресурсы многоядерных систем.
Гвидо ван Россум говорил, что GIL «не так уж и плох» и он будет в CPython до тех пор, пока «кто-то другой» не представит реализацию Python без GIL, с которой бы однопоточные скрипты работали так же быстро^[151][152].
В задачи разработки входит работа по оптимизации GIL^[153]. Отказ от GIL в ближайшем будущем не планируется, так как альтернативные механизмы на однопоточных приложениях, которых большинство, работают медленнее или потребляют больше ресурсов:

• 
  Вариант интерпретатора с синхронизацией доступа к отдельным объектам вместо глобальной блокировки^[154] из-за частых захватов/освобождений блокировок оказался слишком медленным.
  
• 
  python-safethread — CPython без GIL^[155], по утверждениям авторов, обеспечивает на однопоточных приложениях скорость порядка 60-65 % от скорости CPython.
  
• 
  Реализация потоков через процессы ОС, например, модуль processing^[156] (с версии 2.6 переименован в multiprocessing). В UNIX-подобных системах накладные расходы при порождении процесса невелики, но в Windows использование процессов вместо потоков ведёт к существенному увеличению расхода оперативной памяти.
  
• 
  Отказ от совместного использования изменяемых данных и вызовов внешнего кода. При этом данные дублируются в потоках и их синхронизация (если таковая нужна) лежит на программисте^[157]. Этот подход также увеличивает потребление оперативной памяти, хотя и не настолько сильно, как при использовании процессов в Windows.
  
• 
  Библиотеки, обеспечивающие собственную организацию поддержки потоков, такие как parallelpython^[158], pympi^[159] и другие.
  

Радикальным вариантом решения проблемы может быть переход на Jython и IronPython, работающие на виртуальных машинах Java и .NET/Mono: эти реализации вообще не используют GIL.