Qu'est-ce que le GIL et comment affecte-t-il la concurrence ?

Question

Accepted Answer

Le **GIL** (Global Interpreter Lock) est un mutex dans CPython (l'implémentation standard de Python) qui permet à **un seul thread d'exécuter le bytecode Python à la fois**. Cela signifie que les threads Python ne peuvent pas exécuter du code Python en vrai parallèle sur plusieurs cœurs CPU — une considération majeure pour la concurrence.

## Ce que le GIL signifie en pratique

```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.
```

## La distinction clé : 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
```

La nuance cruciale : le GIL est **libéré pendant les I/O** (réseau, fichier, sleep) et à l'intérieur de nombreuses extensions C. Donc les threads *aident* pour les tâches **I/O-bound** (les multiples attentes se chevauchent), mais *pas* pour les tâches **CPU-bound** (le GIL sérialise le calcul).

## Contourner le GIL pour le travail CPU-bound

```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
```

Pour le parallélisme CPU-bound, utilisez **`multiprocessing`** (les processus séparés contournent le GIL unique), ou des bibliothèques (NumPy, etc.) dont le travail intensif s'exécute en C avec le GIL libéré.

## Le guide de décision

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

## L'avenir

```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.
```

## Pourquoi c'est important

Le GIL est l'une des caractéristiques les plus importantes — et les plus mal comprises — de Python.

Il explique *pourquoi* l'utilisation de threads pour du travail intensif en CPU ne donne aucune accélération (une erreur courante), et *pourquoi* l'outil de concurrence correct dépend de la charge de travail : **threading/asyncio pour I/O-bound** (où le GIL est libéré pendant les attentes) et **multiprocessing pour CPU-bound** (processus séparés pour un vrai parallélisme).

Mal comprendre le GIL conduit à un code concurrent inefficace qui ne s'adapte pas.

Le connaître — et la décision I/O-vs-CPU qu'il entraîne — est essentiel pour écrire du Python concurrent qui performe réellement.