🔑 The GIL, Deeply

What the GIL Actually Is

The Global Interpreter Lock is a single mutex inside the CPython interpreter. To run any Python bytecode, a thread must first hold that mutex. Because there is exactly one of them per interpreter, only one thread executes Python bytecode at any instant — even on a 32-core machine.

What does it protect? Chiefly CPython's reference counts. Every object carries a counter of how many references point at it; when it hits zero the object is freed. That counter is touched constantly — on nearly every assignment, function call, and attribute access. If two threads incremented and decremented the same refcount without coordination, counts would corrupt, objects would be freed while still in use, and the interpreter would crash. The GIL makes each bytecode step's refcount bookkeeping safe by fiat.

Why It Exists (It's a Feature, Not Just a Wart)

It's tempting to see the GIL as pure legacy baggage, but it bought CPython three concrete things:

• Fast, simple single-threaded code. Refcounting needs no atomic instructions or fine-grained locks — just plain integer ++/-- under one big lock. That keeps the common (single-threaded) case cheap.
• Simple memory management. No fine-grained locking scattered across every mutable object; the interpreter's internal data structures are protected as a whole.
• Easy C extensions. Extension authors can assume their code runs single-threaded unless they explicitly say otherwise. This is a huge reason the C-extension ecosystem (NumPy, etc.) grew so large and so reliably.

Threads Take Turns Holding It

A running thread doesn't keep the GIL forever. It releases it periodically so other runnable threads get a turn — nobody starves. Conceptually, execution is a relay race where the baton is the GIL:

The interpreter decides when to invite a switch using the switch interval. You can inspect and set it:

import sys

sys.getswitchinterval()   # 0.005  → 5 milliseconds (default)

sys.setswitchinterval(0.001)   # ask for switches every ~1ms

When the GIL Is Released — the Whole Point

Here is the fact that makes threading useful at all: a thread releases the GIL while it waits on something outside the interpreter. During that wait, other Python threads run. So overlapping waiting is exactly what threads are good at.

Note that Py_BEGIN_ALLOW_THREADS is why NumPy can give you real parallelism: a big np.dot releases the GIL and crunches numbers in C (often across multiple BLAS threads) while your other Python threads keep running.

The Consequence: CPU-Bound Threads Don't Speed Up

Because pure-Python CPU work holds the GIL the entire time, two CPU-bound threads cannot run their bytecode at once. They just take turns. Best case you get roughly the sequential time; worst case you get slower, because now you also pay for GIL hand-offs and cache effects.

import time, threading

def burn(n):
    # pure-Python CPU work — holds the GIL the whole time
    x = 0
    for _ in range(n):
        x += 1
    return x

N = 40_000_000

# --- Sequential ---
t0 = time.perf_counter()
burn(N); burn(N)
print("sequential:", round(time.perf_counter() - t0, 2), "s")

# --- Two threads ---
t0 = time.perf_counter()
ts = [threading.Thread(target=burn, args=(N,)) for _ in range(2)]
for t in ts: t.start()
for t in ts: t.join()
print("2 threads: ", round(time.perf_counter() - t0, 2), "s")

Ways Around the GIL

If you genuinely need CPU parallelism in Python, you don't fight the GIL — you sidestep it. Four approaches, roughly in order of how mainstream they are today:

• Multiple processes — multiprocessing or ProcessPoolExecutor. Each process has its own interpreter and its own GIL, so they run bytecode truly in parallel. The cost is that memory isn't shared: arguments and results are pickled across process boundaries, and startup is heavier. This is the standard answer for CPU-bound Python.
• Push the work into C — NumPy, SciPy, Numba, Cython, PyTorch, Polars. These release the GIL and compute in native code, giving real parallelism (and raw speed) without you managing processes.
• Free-threaded CPython (PEP 703, "no-GIL"). An experimental build with the GIL removed entirely, shipping since Python 3.13 as a separate interpreter (python3.13t). In it, CPU-bound threads scale across cores like other languages. It's officially experimental and is maturing through 3.14 and beyond; expect single-threaded slowdowns and C-extension compatibility gaps in the meantime.
• Subinterpreters (PEP 734, per-interpreter GIL). Since Python 3.12 each subinterpreter can have its own GIL, so multiple subinterpreters in one process run bytecode in parallel. Python 3.12 exposes this at the C level; a friendlier standard-library API (concurrent.interpreters) arrives in 3.14. It's lighter than processes but still isolates most state.

# CPU-bound → separate processes = real parallelism, one GIL each
from concurrent.futures import ProcessPoolExecutor

def burn(n):
    x = 0
    for _ in range(n):
        x += 1
    return x

with ProcessPoolExecutor() as pool:
    results = list(pool.map(burn, [40_000_000] * 4))
# on a 4-core box this is ~4x faster than doing it in threads

Key Takeaways