Was ist der GIL und wie beeinflusst er Concurrency?

Question

Accepted Answer

Der **GIL** (Global Interpreter Lock) ist ein Mutex in CPython (der Standard-Python-Implementierung), der es nur **einem Thread erlaubt, Python-Bytecode gleichzeitig auszuführen**. Das bedeutet, Python-Threads können Python-Code nicht wirklich parallel auf mehreren CPU-Kernen ausführen — ein wichtiger Aspekt bei der Concurrency-Programmierung.

## Was der GIL in der Praxis bedeutet

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

## Die entscheidende Unterscheidung: CPU-gebunden vs. I/O-gebunden

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

Die wichtige Nuance: Der GIL wird **während I/O** (Netzwerk, Datei, Sleep) und innerhalb vieler C-Erweiterungen **freigegeben**. Threads helfen also *wirklich* bei **I/O-gebundenen** Aufgaben (mehrere Waits überlappen sich), aber *nicht* bei **CPU-gebundenen** Aufgaben (der GIL serialisiert die Berechnung).

## Den GIL für CPU-gebundene Arbeit umgehen

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

Für CPU-gebundene Parallelisierung verwenden Sie **`multiprocessing`** (separate Prozesse umgehen den einzelnen GIL), oder Bibliotheken (NumPy usw.), deren schwere Arbeit in C mit freigegebenem GIL läuft.

## Der Entscheidungsleitfaden

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

## Die Zukunft

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

## Warum es wichtig ist

Der GIL ist eine der wichtigsten — und am häufigsten missverstandenen — Eigenschaften von Python.

Er erklärt, *warum* die Verwendung von Threads für CPU-intensive Arbeit keine Geschwindigkeitssteigerung bringt (ein häufiger Fehler), und *warum* das richtige Concurrency-Werkzeug von der Workload abhängt: **Threading/Asyncio für I/O-gebunden** (wo der GIL während Waits freigegeben wird) und **Multiprocessing für CPU-gebunden** (separate Prozesse für echte Parallelisierung).

Missverständnis des GIL führt zu ineffektiver Concurrency-Code, der nicht skaliert.

Wenn man ihn versteht — und die I/O-vs-CPU-Entscheidung, die er antreibt — ist es wesentlich, um concurrent Python zu schreiben, das tatsächlich performant ist.