Hva er GIL og hvordan påvirker det concurrency?

Question

Accepted Answer

**GIL** (Global Interpreter Lock) er en mutex i CPython (standard Python-implementasjonen) som tillater bare **én tråd å kjøre Python bytecode om gangen**. Dette betyr at Python-tråder ikke kan kjøre Python-kode i ekte parallellitet på flere CPU-kjerner — en viktig vurdering for concurrency.

## Hva GIL betyr 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.
```

## Den viktige distinksionen: 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 kritiske nyanseringen: GIL er **frigitt under I/O** (nettverk, fil, sleep) og inne i mange C-utvidelser. Så tråder *hjelper* for **I/O-bundet** arbeid (flere venter overlapper), men *ikke* for **CPU-bundet** arbeid (GIL serialiserer beregningen).

## Arbeide rundt GIL for CPU-bundet arbeid

```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 parallellisme, bruk **`multiprocessing`** (separate prosesser omgår den enkelte GIL), eller biblioteker (NumPy, osv.) hvis tunge arbeid kjører i C med GIL frigitt.

## Beslutningsveiledning

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

GIL er en av Pythons viktigste — og mest misforståtte — egenskaper.

Det forklarer *hvorfor* bruk av tråder for CPU-tungt arbeid gir ingen hastighetsøkning (en vanlig feil), og *hvorfor* det riktige concurrency-verktøyet avhenger av arbeidsmengden: **threading/asyncio for I/O-bundet** (der GIL frigis under venting) og **multiprocessing for CPU-bundet** (separate prosesser for ekte parallellisme).

Misforståelse av GIL fører til ineffektiv concurrency-kode som ikke skaleres.

Å kjenne det — og I/O-vs-CPU-beslutningen det driver — er essensielt for å skrive concurrent Python som faktisk presterer.