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

Глобальная блокировка интерпретатора (англ. Global Interpreter Lock, GIL) — способ синхронизации потоков, который используется в некоторых интерпретируемых языках программирования, например в Python и Ruby.

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

Суть концепции

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].

Реализации интерпретаторов на JVM (Jython, JRuby) и на .NET (IronPython, IronRuby) не используют GIL[9][10].

В рамках проекта PyPy ведётся работа по реализации транзакционной памяти (англ. Software Transactional Memory, SТМ). На данный момент[какой?] даже в многопоточных вычислениях интерпретатор с STM работает во много раз медленней, чем с GIL. Но за счёт JIT PyPy-STM[11] всё равно быстрее, чем CPython[12].

Примечания
  1. Thread State and the Global Interpreter Lock
  2. Antoine Pitrou. Reworking the GIL. Python Mailing Lists (25 октября 2009).
  3. Описание GIL. Python Wiki.
  4. David Beazley. Inside the Python GIL. Chicago: Chicago Python User Group (11 июня 2009). Дата обращения: 7 октября 2009.
  5. Shannon -jj Behrens. Concurrency and Python 2. Dr. Dobb's Journal (3 февраля 2008). Дата обращения: 12 июля 2008.
  6. An open letter to Guido van Rossum: Mr Rossum, tear down that GIL! (недоступная ссылка). SnapLogic (9 сентября 2007). Архивировано 24 декабря 2013 года.
  7. Guido van Rossum. the future of the GIL. Python Mailing Lists (8 мая 2007).
  8. Guido van Rossum. It isn't Easy to Remove the GIL. artima.com (10 сентября 2007).
  9. WhyJython. Python Wiki.
  10. IronPython. Python Wiki. Дата обращения: 4 апреля 2011.
  11. Архивная копия от 24 декабря 2013 на Wayback Machine PyPy-STM on Bitbucket
  12. Update on STM. Python Wiki (16 октября 2013).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.