What is the Global Interpreter Lock (GIL), and why does it exist in CPython?
The GIL is a mutex that serializes bytecode execution in CPython to protect interpreter state
The GIL is a single mutex held by the thread that is currently executing Python bytecode. Only one thread runs Python code at a time, even on a multi-core machine. It exists because CPython's memory management is reference counting, and reference count updates are not atomic. Without a global lock, two threads could decrement the same object's refcount simultaneously and either free memory twice or leak it, and other shared interpreter structures such as the object allocator, interned strings, and the small-int cache would race. Making every refcount atomic would be possible but historically imposed a large single-threaded slowdown, so CPython chose a coarse lock that is cheap when uncontended. The GIL is not a language feature: it is a CPython implementation detail, and Jython and IronPython never had one.
- 1
The GIL is released periodically so other threads can run, and it is released around blocking IO and some C extension calls.
- 2
It protects interpreter-level state, not your application state. You still need locks for your own shared mutable data.
- 3
Workloads that release the GIL in C (numpy, hashlib, zlib, psycopg, file IO) can run in parallel across threads.
- 4
Trade-off: the GIL makes single-threaded CPython fast and C extensions simple, at the cost of CPU parallelism for pure Python threads.
- 5
Common mistake: claiming Python is single-threaded. It is not; multiple threads exist but only one executes bytecode at a time.
- 6
Common mistake: thinking the GIL makes your code thread-safe. It does not; individual bytecode operations are atomic, but sequences of them are not.
- 7
Version note: PEP 703 proposes an optional no-GIL build, and free-threaded builds became experimentally available in 3.13. Do not assume this in production yet; verify the build and library support.
Scenario Questions
0-2 years experience
- 1You start ten threads that run pure Python loops and see no speedup. Why?
- 2Does the GIL protect a shared list from concurrent appends?
2-5 years experience
- 1You write a service with threads that do HTTP calls and see throughput improve. Why, given the GIL?
- 2You believe the GIL makes your code safe from races. What counterexample shows this is false?
5-8 years experience
- 1You are designing a service that mixes CPU and IO work. How does the GIL change your architecture?
- 2A C extension in your stack releases the GIL. What implications does that have for latency and correctness?
8+ years experience
- 1Compare the impact of a free-threaded CPython build on your existing codebase's assumptions about thread safety and C extensions.
- 2Explain how the GIL interacts with signal handling, fork, and at-fork handlers in a production service.
Follow-up Questions
- Does the GIL make your Python code thread-safe? Why or why not?
- What changes in Python 3.13+ with free-threaded builds, and what trade-offs do they introduce?