Real parallelism, executors, and the GIL

Separate processes for genuine CPU parallelism, one executor API for both threads and processes, and the lock that decides which one actually helps

Process, not Threadown interpreter, own memory, own GIL — real parallelism
Everything is pickledarguments, results, Queue/Pipe items — all serialized across
as_completed()process results in FINISH order, not submission order
The GILblocks CPU-bound threading; I/O-bound threading still works

1.What the GIL is, and why it exists

The GIL is a mutex inside CPython letting only one thread execute Python bytecode at a time — even on multiple cores, two threads never run Python code simultaneously. It exists because reference counting is not thread-safe without it.

Key features

The GIL is one mutex per CPython process — only one thread runs Python bytecode at a time
It exists to make reference counting safe without a lock on every single object
Threads take turns — the interpreter switches which one holds the GIL, roughly every 5ms
A CPython implementation detail, not a language requirement — Jython/IronPython have none
Python 3.13+ has an experimental free-threaded build (PEP 703) — not this machine's build

Where the GIL is, and is not, a CPython implementation detail

Where the GIL is, and is not, a CPython implementation detail
Claim	True?
The GIL is part of the Python language specification	false — it is specific to CPython, the reference implementation
Every CPython object's reference count needs GIL protection to update safely	true — this is the reason the GIL exists
Threads never make progress on Python bytecode without holding the GIL	true — by definition, since it gates bytecode execution
The GIL prevents all forms of concurrency in Python	false — I/O-bound concurrency still works well; see the paired concept

One GIL per process — only its holder runs Python bytecode

4 threads

in one process

the GIL

held by exactly one thread at a time

1 thread runs bytecode

the other 3 wait their turn

Command

python

import sys

# True on a standard build; False on a free-threaded (PEP 703) 3.13+ build
print(sys._is_gil_enabled())

The GIL is one mutex per CPython process, letting only one thread run bytecode at a time. A CPython detail, not a language rule.

2.The GIL in practice — CPU-bound vs. I/O-bound, and what to reach for

For CPU-bound work, threads do not speed things up — the GIL lets only one run bytecode at a time. For I/O-bound work, threads genuinely help, since waiting releases the GIL. Multiprocessing for CPU parallelism; threading/async for waiting.

Key features

CPU-bound + threading: little/no speedup — measured here, 2 threads was SLOWER than serial
CPU-bound + multiprocessing: real speedup — each process has its own GIL, runs in parallel
I/O-bound + threading: real speedup — a blocked thread releases the GIL for others to use
A C extension (NumPy, many I/O libs) can release the GIL internally during native code
Rule of thumb: CPU-bound → multiprocessing; I/O-bound → threading or asyncio

Measured effect of the GIL, this machine, Python 3.14.3

Measured effect of the GIL, this machine, Python 3.14.3
Workload	Serial	Threaded (2)	Multiprocess (2)
CPU-bound (5M-iteration sum, twice)	0.641s	0.757s — slower	0.470s — faster
I/O-bound (0.3s sleep, twice)	0.601s	0.302s — ~2x faster	not applicable

Match the tool to the workload

CPU-bound?

busy computing, not waiting

multiprocessing

separate GILs — real parallelism

I/O-bound?

mostly waiting on network/disk

Command

python

# Decision: what is the code actually doing while it "works"?
#   Busy computing (loops, math, parsing)     -> CPU-bound  -> multiprocessing
#   Waiting (network, disk, sleep, DB query)   -> I/O-bound   -> threading / asyncio

CPU-bound: reach for multiprocessing — threading rarely helps, can be slower. I/O-bound: reach for threading/asyncio — a blocked thread releases the GIL.

Spotted a mistake on this page? Tell us.

Read Sheet