Use for questions concerning CPython's Global Interpreter Lock
The Global Interpreter Lock (GIL) is a CPython implementation detail that ensures thread safety by disallowing concurrent execution of Python code. Python versions such as CPython (the Python reference implementation), Stackless Python and PyPy have the GIL; versions such as Jython and IronPython do not.
Python's Global Interpreter Lock (GIL) is a global mutex which ensures that only one thread of the interpreter can run Python bytecode at one time. It is the underlying mechanism that allows CPython as a whole to be thread-safe, despite parts of the interpreter such as garbage collection not being thread safe. While the GIL prevents concurrent threaded execution of Python code, code that waits for I/O like filesystem or database calls and code that does lengthy number-crunching in C (such as NumPy functions) will release the GIL to allow other threads to execute.
Versions of Python that run on virtual machines such as Jython and IronPython do not have a GIL, primarily because they can rely on the virtual machine to provide fully thread-safe garbage collection without reference counting.
The GIL has become the point of some contention as Python has evolved, because it constrains the performance of massively threaded programs, even on multi-CPU platforms which can otherwise execute code in parallel.
The defenders of the GIL (most notably GvR, the original creator of Python) argue that the GIL makes writing Python extensions simpler (because they can safely assume that only they are running), and that removing the GIL would necessitate more fine-grained mutexes that would impact single-threaded performance. The Python Wiki has more details on challenges with removing the GIL.
Various projects have aimed to remove the GIL, including:
- A fork of Python from 1999, which died out due to poor single-threaded performance
- Unladen Swallow
- An experimental PyPy project to replace the GIL with transactional memory
Using Python on multiple cores is still possible using multiple processes (e.g. with the multiprocessing module), but communication between multiple processes is more difficult than communication between multiple threads on the same process. Also, spawning a process uses more CPU time and memory than spawning a thread.
More information on the GIL:
