GIL является самым простым способом избежать конфликтов при одновременном обращении разных потоков к одним и тем же участкам памяти[1]. Когда один поток захватывает его, GIL, работая по принципу мьютекса, блокирует остальные. Нет параллельных потоков — нет конфликтов при обращении к разделяемым объектам. Очерёдность выполнения потоков определяет интерпретатор в зависимости от реализации, переключение между потоками может происходить: когда активный поток пытается осуществить ввод-вывод, по исчерпании лимита выполненных инструкций, либо по таймеру[2].
Преимущества и недостатки
Главный недостаток подхода обеспечения потокобезопасности при помощи GIL — это ограничение параллельности вычислений. GIL не позволяет достигать наибольшей эффективности вычислений при работе на многоядерных и мультипроцессорных системах[3]. Также использование нескольких потоков накладывает издержки на их переключение из-за эффекта конкуренции (потоки «пытаются» перехватить GIL). То есть многопоточное выполнение может занять большее время, чем последовательное выполнение тех же задач[4].
Причины использования GIL:
Однопоточные сценарии выполняются значительно быстрее, чем при использовании других подходов обеспечения потокобезопасности;
Простая интеграция библиотек на C, которые зачастую тоже не потокобезопасны;
Простота реализации.
Применение
GIL используется в CPython'е, наиболее распространённой реализации интерпретатора языка Python[5], и в Ruby MRI, эталонной реализации интерпретатора языка Ruby, где он зовётся Global VM Lock.
В сети не раз появлялись петиции и открытые письма с просьбой убрать GIL из Python'а[6]. Однако создатель и «великодушный пожизненный диктатор» проекта Гвидо ван Россум заявляет, что GIL не так уж и плох и он будет в CPython'е до тех пор, пока кто-то другой не представит реализацию Python'а без GIL, с которой бы однопоточные скрипты работали так же быстро[7][8].
В рамках проекта PyPy ведётся работа по реализации транзакционной памяти (Шаблон:Lang-en). На данный моментШаблон:Какой даже в многопоточных вычислениях интерпретатор с STM работает во много раз медленней, чем с GIL. Но за счёт JIT PyPy-STM[11] всё равно быстрее, чем CPython[12].
