CPython: the GIL and free-threading

The Global Interpreter Lock is a single mutex inside the CPython interpreter. Any thread that wants to execute Python bytecode must first hold it, so only one thread runs Python code at a time, even on a 32-core machine. It is a property of the CPython implementation, not the language: Jython and IronPython have no GIL.

import threading

counter = 0
def work():
    global counter
    for _ in range(1_000_000):
        counter += 1     # load, add, store: three separate bytecodes

ts = [threading.Thread(target=work) for _ in range(4)]

Running those four threads does not use four cores for the loop; they take turns holding the GIL. For CPU-bound Python, threads give concurrency (interleaving) but not parallelism (running at the same instant).

The GIL is not an accident to apologize for; it buys real simplicity. Reference counting touches a counter on every object operation. Without a global lock, each increment and decrement would need an atomic instruction or a per-object lock, which slows the single-threaded path that most Python code runs on.

The GIL also protects the interpreter's own mutable state, dict internals, the small-object allocator, module state, without fine-grained locks scattered everywhere. And it makes C extensions far easier to write: an author can assume their code will not be preempted by another Python thread mid-operation. For decades this trade, fast single-threaded execution and simple C interop in exchange for no in-process parallelism, was judged worth it.

The GIL blocks parallelism for CPU-bound Python, but two escape hatches matter.

First, the GIL is released around blocking I/O: while a thread waits on a socket, disk, or time.sleep, it drops the lock so others run. So threads do give real speedups for I/O-bound work: many concurrent requests, file reads, database calls.

Second, C extensions can release it during heavy computation. NumPy, hashlib, compression, and image libraries wrap long C loops so a matrix multiply on one thread runs alongside Python on another.

from concurrent.futures import ThreadPoolExecutor
# I/O-bound: threads help because the GIL is dropped while waiting
with ThreadPoolExecutor(8) as ex:
    results = list(ex.map(fetch_url, urls))

Rule of thumb: threads for I/O, processes for CPU.

CPython offers three ways to run work concurrently, and the GIL is why the choice matters.

multiprocessing sidesteps the GIL by running separate interpreter processes, each with its own GIL, communicating by pickling data across pipes, which costs serialization and memory. asyncio runs a single thread with an event loop, switching cooperatively at await points, ideal for tens of thousands of open sockets. Choose by the bottleneck: waiting favors threads or async, computing favors processes.

A thread does not hold the GIL forever. Periodically the running thread hits the eval breaker, a check in the evaluation loop, and if another thread is waiting it releases and reacquires the lock. The cadence is the switch interval, about 5 milliseconds by default.

import sys
sys.getswitchinterval()      # 0.005
sys.setswitchinterval(0.010) # check less often

The handoff happens between bytecode instructions, never inside one, but a single Python statement is many instructions. counter += 1 compiles to a load, an add, and a store; two threads can interleave so both load the same value before either stores, and an update is lost. The GIL makes each bytecode effectively atomic, not each line. Compound updates still need a threading.Lock.

PEP 703 adds a build of CPython, the free-threaded build, where the GIL is disabled and multiple threads execute Python bytecode truly in parallel. It first shipped as an experimental, compile-time option in 3.13 and reached officially supported status in 3.14 under PEP 779, with any default-on switch left for later years.

Removing the GIL means everything it implicitly protected now needs explicit protection. Free-threading replaces the one big lock with fine-grained per-object locks plus atomic operations on shared interpreter state. Operations on a dict or list that used to be safe purely because 'only one thread runs' now take a lightweight per-object lock instead. The stated goal is real multi-core scaling for CPU-bound Python without changing what your code means.

The hardest part of dropping the GIL is reference counting: a naive shared counter would need an atomic add on every increment and decrement, which is slow and causes cache-line contention when many threads touch the same hot object. The free-threaded build combines three techniques.

• Biased reference counting: each object has an owner thread that updates the count with cheap non-atomic ops on a fast path, while other threads use a separate atomic path. Most objects are touched mainly by their owner.
• Deferred reference counting: references held on interpreter stacks are not counted continuously, cutting churn on very hot objects.
• Immortal objects: singletons such as None, True, False, small ints, and interned strings are marked immortal; their counts never change, so threads never contend on them.

Together these keep the common path fast while making counting correct across cores.

Free-threading is not free, which is why it stayed opt-in.

• Single-threaded overhead: the extra bookkeeping makes the no-GIL build somewhat slower on one thread than the standard build, a gap later releases keep narrowing.
• C-extension compatibility: extensions written assuming the GIL must be audited and rebuilt for the free-threaded ABI; unmodified C code can crash or corrupt state under true parallelism, so the ecosystem migrates gradually.
• A new bug class: code that was accidentally safe 'because the GIL' can now race, so existing threaded Python may need real locks it previously got away without.

The GIL is becoming a choice rather than a fixed fact of CPython.

The decision hinges on the bottleneck and, now, on which build you run. Waiting work parallelizes under the GIL; computing work needs processes or the free-threaded build.