Hvad er GIL, og hvordan påvirker det samtidighed?

Question

Accepted Answer

**GIL** (Global Interpreter Lock) er en mutex i CPython (standard Python-implementeringen), der tillader kun **én tråd at udføre Python bytecode ad gangen**. Dette betyder, at Python-tråde ikke kan køre Python-kode i ægte parallel på flere CPU-kerner — en vigtig overvejelse for samtidighed.

## Hvad GIL betyder i praksis

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

## Vigtige sondringen: CPU-bundet vs I/O-bundet

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

Den afgørende nuance: GIL **frigøres under I/O** (netværk, fil, sleep) og inden i mange C-udvidelser. Så tråde *hjælper* til **I/O-bundet** arbejde (flere ventilier overlapper), men *ikke* til **CPU-bundet** arbejde (GIL serialiserer beregning).

## Omgå GIL for CPU-bundet arbejde

```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-bundet parallelisme skal du bruge **`multiprocessing`** (separate processer omgår den enkelte GIL), eller biblioteker (NumPy osv.), hvis tunge arbejde kører i C med GIL frigøret.

## Beslutningsvejledningen

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

## Fremtiden

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

## Hvorfor det betyder noget

GIL er en af Pythons vigtigste — og mest misforståede — karakteristika.

Det forklarer *hvorfor* brug af tråde til CPU-tungt arbejde giver ingen speedup (en almindelig fejl), og *hvorfor* det rigtige samtidigheds-værktøj afhænger af arbejdsbyrden: **threading/asyncio til I/O-bundet** (hvor GIL frigøres under ventilier) og **multiprocessing til CPU-bundet** (separate processer for ægte parallelisme).

Misforståelse af GIL fører til ineffektiv samtidighedskode, der ikke skaleres.

At kende det — og den I/O-vs-CPU-beslutning, det driver — er væsentligt for at skrive samtidig Python, der faktisk fungerer.