The GIL, and free-threaded Python

Article.

The most-changed Python interview topic in years. The GIL still exists in the default build, but since Python 3.14 the free-threaded build is officially supported (PEP 779), and answering as if the GIL were permanent dates you. What does the GIL actually guarantee, what did it never guarantee, and what changes when it is gone?

Numbers below are from CPython 3.14.5, with and without the GIL, using 4 threads on a 12-thread Windows machine.

What the GIL is, and why it exists

A per-interpreter lock: only the thread holding it may execute Python bytecode. It exists because CPython manages memory by reference counting, and reference counts change on almost every operation. Making each increment atomic would slow every program; one coarse lock was cheaper (Python memory model — allocation, refcounting, GC).

How threads take turns

Since Python 3.2 a waiting thread does not spin. It waits up to the switch interval, sys.getswitchinterval(), 5 ms by default, then sets a “drop request” flag. The running thread checks that flag at safe points of the interpreter loop (function calls, backward jumps), releases the GIL, and the waiting thread takes it.

C code that blocks or computes for long releases the GIL explicitly (Py_BEGIN_ALLOW_THREADS around read(), sleep(), a NumPy kernel), which is why I/O threads overlap.

The convoy effect

An I/O-bound thread next to a CPU-bound one suffers. Every time the I/O thread’s call returns, it must take the GIL back from the CPU thread, which can mean waiting a full switch interval, so a thread that does thousands of short I/O operations a second slows to a crawl.

Lowering sys.setswitchinterval() shortens the waits at the cost of more switching; the real fixes are moving the CPU work to a process or a free-threaded build, or the I/O to asyncio.

What the GIL never protected

counter = 0

def bump(n):
    global counter
    for _ in range(n):
        counter += 1          # read, add, write: three steps

# two threads, a million each

On the GIL build the count came out exact, and stayed exact with a function call inside the update. That is not correctness: the GIL can switch threads between the read and the write, it just rarely does at that exact point with a 5 ms interval. The free-threaded build runs both threads at once and loses half the updates.

The GIL made races rare, never impossible; code that shares mutable state needs a Lock on either build (Synchronization primitives).

The free-threaded build

python3.14t -c "import sys; print(sys._is_gil_enabled())"    # False

It is a separate build of CPython (wheels are tagged cp314t), opt-in, and not the default; no date has been set for making it one. What it changes:

CPU-bound threads finally scale across cores. The price is single-threaded speed: about 16% in this tight loop, while the 3.14 release notes put the typical cost at 5-10% (3.13t was much slower, because the specialising interpreter was disabled there).

How it works without the GIL

• Biased reference counting. Each object has a cheap non-atomic count for the thread that created it and an atomic count for every other thread.
• Immortal and deferred objects. Immortal objects (PEP 683) are never counted; for heavily shared ones such as functions and modules, counting is deferred to the garbage collector.
• Per-object locks. list and dict operations take a lightweight lock on the object (a “critical section”), so built-in containers stay internally consistent. Your read-modify-write sequences are not.
• mimalloc, a thread-safe allocator, replaces pymalloc, and memory is reclaimed only once no thread can still be reading it.

What else changes

• Extensions can switch the GIL back on. An extension module that does not declare free-threading support (the Py_mod_gil slot set to Py_MOD_GIL_NOT_USED) re-enables the GIL when imported, with a RuntimeWarning. Check sys._is_gil_enabled() after imports; force it off with PYTHON_GIL=0 or -X gil=0 only after testing that extension.
• Threads inherit context variables. On 3.14t sys.flags.thread_inherit_context is 1 (it is 0 on the GIL build): a new thread starts with a copy of the caller’s contextvars. Request IDs and logging context now follow work into threads, which helps, and surprises code that relied on a clean slate.

Four concurrency models

from concurrent.futures import InterpreterPoolExecutor      # 3.14

with InterpreterPoolExecutor(max_workers=4) as pool:
    results = list(pool.map(score, chunks))     # args and results are pickled

Subinterpreters (PEP 734, concurrent.interpreters in 3.14) run in one process, each with its own GIL. Creating one and running a first statement took 21 ms here, against 254 ms to spawn a process on Windows. The docs list the current limits: start-up is not yet optimised, each uses more memory than it needs to, and many extension modules on PyPI do not support them yet.

Choosing, in 2026

• I/O-bound with async libraries → asyncio, still the default for network services.
• I/O-bound with blocking libraries → threads, on either build.
• CPU-bound in NumPy, Polars or PyTorch → often already parallel inside the library; measure first.
• CPU-bound pure Python → processes are the safe default. The free-threaded build with threads is the direction of travel where your dependencies support it and your code is audited for races; subinterpreters fit shared-nothing work in between.

Where it breaks in production

Races that were always there

Moving to 3.14t turns rare races into frequent ones: counters that drift, check-then-act on a dict, lazily initialised singletons built twice. They were bugs on the GIL build too. Run the test suite under 3.14t with many threads before trusting it; lock shared state.

The GIL quietly comes back

A single dependency without free-threading support re-enables the GIL for the whole process, and the deployment shows no speed-up. Check after the imports, at start-up:

import sys, sysconfig

if sysconfig.get_config_var("Py_GIL_DISABLED"):    # a free-threaded build
    assert not sys._is_gil_enabled(), "an extension re-enabled the GIL"

The RuntimeWarning printed at import names the module responsible.

Latency from GIL contention

A service mixing CPU-heavy work (JSON of large payloads, template rendering) with I/O threads shows high latency the CPU graphs do not explain: the convoy effect. py-spy dump or py-spy top --gil shows which threads hold the GIL.

The trade not taken

Removing the GIL by making every reference count atomic was tried (the “Gilectomy”) and made single-threaded code far slower. PEP 703’s biased reference counting keeps the common case cheap, which is why free-threading was accepted. The conservative alternative remains: keep the GIL and use processes or subinterpreters for parallel CPU work, isolating state instead of locking it. For most services that is still the lower-risk choice in 2026.

Related

• Concurrency and parallelism - the two words, defined
• Threads and processes - threads and processes compared
• CPU-bound versus I/O-bound - choosing by workload
• Synchronization primitives - locks for shared state
• Python memory model — allocation, refcounting, GC - reference counting, with and without the GIL