What is the GIL and how does it affect concurrency?

Question

Accepted Answer

The **GIL** (Global Interpreter Lock) is a mutex in CPython (the standard Python implementation) that allows only **one thread to execute Python bytecode at a time**. This means Python threads cannot run Python code in true parallel on multiple CPU cores — a major consideration for concurrency.

## What the GIL means in practice

```text
Even with multiple threads on a multi-core CPU:
  Only ONE thread runs Python bytecode at any instant.
→ Threading does NOT give CPU-bound parallelism in CPython.
```

## The key distinction: CPU-bound vs I/O-bound

```python
import threading

# ❌ CPU-bound work with threads — NO speedup (GIL serializes them)
def cpu_task():
    sum(i * i for i in range(10_000_000))   # heavy computation
# 4 threads doing this run essentially as slow as 1 (GIL contention)

# ✅ I/O-bound work with threads — REAL benefit
def io_task():
    response = requests.get(url)   # waits on network — RELEASES the GIL while waiting
# while one thread waits on I/O, the GIL is freed for others → concurrency works
```

The crucial nuance: the GIL is **released during I/O** (network, file, sleep) and inside many C extensions. So threads *do* help for **I/O-bound** work (multiple waits overlap), but *not* for **CPU-bound** work (the GIL serializes computation).

## Working around the GIL for CPU-bound work

```python
from multiprocessing import Pool

# ✅ multiprocessing uses separate PROCESSES, each with its own GIL → true parallelism
with Pool(4) as p:
    results = p.map(cpu_task, data)   # runs on 4 cores genuinely in parallel
```

For CPU-bound parallelism, use **`multiprocessing`** (separate processes sidestep the single GIL), or libraries (NumPy, etc.) whose heavy work runs in C with the GIL released.

## The decision guide

```text
I/O-bound (network, files, DB)  → threading or asyncio (GIL released on I/O)
CPU-bound (computation)          → multiprocessing (or C-extension libraries)
```

## The future

```text
Python 3.13+ introduces an EXPERIMENTAL free-threaded (no-GIL) build,
and work continues to reduce the GIL's impact — but it remains the default reality.
```

## Why it matters

The GIL is one of Python's most important — and most misunderstood — characteristics.

It explains *why* using threads for CPU-heavy work gives no speedup (a common mistake), and *why* the correct concurrency tool depends on the workload: **threading/asyncio for I/O-bound** (where the GIL is released during waits) and **multiprocessing for CPU-bound** (separate processes for true parallelism).

Misunderstanding the GIL leads to ineffective concurrency code that doesn't scale.

Knowing it — and the I/O-vs-CPU decision it drives — is essential for writing concurrent Python that actually performs.