global interpreter lock
{{Short description|Mechanism that ensures threads are not executed in parallel}}
[[File:GIL description.gif|thumb|250px|
Schematic representation of how threads work under GIL. Green - thread holding GIL, red - blocked threads]]
A global interpreter lock (GIL) is a mechanism used in computer-language interpreters to synchronize the execution of threads so that only one native thread (per process) can execute basic operations (such as memory allocation and reference counting) at a time.{{cite web|title=GlobalInterpreterLock|url=https://wiki.python.org/moin/GlobalInterpreterLock|accessdate=30 November 2015}} As a general rule, an interpreter that uses GIL will see only one thread to execute at a time, even if it runs on a multi-core processor, although some implementations provide for CPU intensive code to release the GIL, allowing multiple threads to use multiple cores. Some popular interpreters that have a GIL are CPython and Ruby MRI.
Technical background concepts
A global interpreter lock (GIL) is a mutual-exclusion lock held by a programming language interpreter thread to avoid sharing code that is not thread-safe with other threads. In implementations with a GIL, there is always one GIL for each interpreter process.
Applications running on implementations with a GIL can be designed to use separate processes to achieve full parallelism, as each process has its own interpreter and in turn has its own GIL. Otherwise, the GIL can be a significant barrier to parallelism.
Advantages
Reasons for employing a global interpreter lock include:
- increased speed of single-threaded programs (no necessity to acquire or release locks on all data structures separately),
- easy integration of C libraries that usually are not thread-safe,
- ease of implementation (having a single GIL is much simpler to implement than a lock-free interpreter or one using fine-grained locks).
A way to get around a GIL is creating a separate interpreter per thread, which is too expensive with most languages.{{Citation needed|date=March 2023}}
Drawbacks
Use of a global interpreter lock in a language effectively limits the amount of parallelism reachable through concurrency of a single interpreter process with multiple threads. If the process is almost purely made up of interpreted code and does not make calls outside of the interpreter which block for long periods of time (allowing the GIL to be released by that thread while they process), there is likely to be very little increase in speed when running the process on a multiprocessor machine. Due to signaling with a CPU-bound thread, it can cause a significant slowdown, even on single processors.{{cite web | url=http://www.dabeaz.com/python/GIL.pdf | title=Inside the Python GIL |author-link=David M. Beazley| author=David Beazley | publisher=Chicago Python User Group | date=2009-06-11 | location=Chicago | accessdate=2009-10-07}} More seriously, when the single native thread calls a blocking OS process (such as disk access), the entire process is blocked, even though other application threads may be waiting.
Examples
Some language implementations that implement a global interpreter lock are CPython, the most widely-used implementation of Python,{{cite web
| url=http://www.ddj.com/linux-open-source/206103078?pgno=2
| title=Concurrency and Python
| page=2
| author=Shannon -jj Behrens
| publisher=Dr. Dobb's Journal
| quote=The GIL is a lock that is used to protect all the critical sections in Python. Hence, even if you have multiple CPUs, only one thread may be doing "pythony" things at a time.
| date=2008-02-03
| accessdate=2008-07-12}}{{Cite web |url=https://docs.python.org/api/threads.html |title=Python/C API Reference Manual: Thread State and the Global Interpreter Lock |access-date=2014-08-15 |archive-url=https://web.archive.org/web/20080914102629/http://docs.python.org/api/threads.html |archive-date=2008-09-14 |url-status=dead }} and Ruby MRI, the reference implementation of Ruby (where it is called Global VM Lock).
JVM-based equivalents of these languages (Jython and JRuby) do not use global interpreter locks. IronPython and IronRuby are implemented on top of Microsoft's Dynamic Language Runtime and also avoid using a GIL.{{cite web
| url=https://wiki.python.org/moin/IronPython
| title=IronPython at python.org
| publisher=python.org
| quote=IronPython has no GIL and multi-threaded code can use multi core processors.
| accessdate=2011-04-04}}
An example of an interpreted language without a GIL is Tcl, which is used in the benchmarking tool HammerDB.{{cite web | url=https://www.hammerdb.com/blog/uncategorized/hammerdb-concepts-and-architecture/ | title=HammerDB Concepts and Architecture |author-link=David M. Beazley| publisher=HammerDB | date=2018-11-30 | quote=It is important to understand at the outset that HammerDB is written in TCL because of the unique threading capabilities that TCL brings. | accessdate=2020-05-10}}
Example code
Example code in Python. Notice how a lock is acquired and released between each instruction call. It uses the {{Mono|Lock}} object from the {{Mono|threading}} module.{{cite web |title=threading — Thread-based parallelism |url=https://docs.python.org/3/library/threading.html#lock-objects |website=Python documentation |access-date=16 April 2025 |language=en}}
from threading import Lock
INSTRUCTION_TABLE = { ... }
def execute(bytecode: list) -> None:
"""Execute bytecode."""
lock = Lock()
for (opcode, args) in bytecode:
lock.acquire()
INSTRUCTION_TABLE[opcode](args)
lock.release()