Wat is de GVL en hoe werkt concurrency in Ruby?

Question

IT Interview Practice · Accepted Answer

De **GVL** (Global VM Lock, voorheen GIL) in MRI Ruby staat slechts **één thread toe om Ruby-code tegelijk uit te voeren** — dus threads bieden geen echte CPU-parallelisme. Maar de GVL wordt **vrijgegeven tijdens I/O**, dus threads *helpen wel* bij I/O-gebonden werk. Voor CPU-parallelisme gebruik je meerdere processen. Dit weerspiegelt de GIL-situatie in Python.

## De GVL: één thread voert Ruby-code tegelijk uit

```text
MRI (the standard Ruby) has a GLOBAL VM LOCK:
  → only ONE thread executes Ruby code at any instant (no CPU parallelism from threads)
  → BUT the GVL is RELEASED during blocking I/O (network, file, DB)
So: threads help for I/O-bound work, NOT for CPU-bound work.
```

## Threads — goed voor I/O-gebonden concurrency

```ruby
# ✅ I/O-bound — threads overlap waiting (GVL released during I/O) → real benefit
threads = urls.map do |url|
  Thread.new { fetch(url) }      # while one waits on the network, others proceed
end
threads.each(&:join)

# ❌ CPU-bound — threads do NOT speed this up (GVL serializes Ruby execution)
threads = data.map { |d| Thread.new { heavy_computation(d) } }  # no speedup
```

Threads helpen bij I/O-gebonden werk (netwerk, bestand, DB) omdat de GVL wordt vrijgegeven tijdens het wachten, waardoor andere threads kunnen draaien. Ze versnellen **niet** CPU-gebonden werk (de GVL serialiseert Ruby-uitvoering).

## Processen — voor CPU-gebonden parallelisme

```ruby
# ✅ CPU-bound parallelism → use multiple PROCESSES (each has its own GVL)
# fork, or gems like Parallel:
results = Parallel.map(data, in_processes: 4) { |d| heavy_computation(d) }
# → 4 separate processes, true parallelism across cores
```

Voor CPU-gebonden parallelisme gebruik je **meerdere processen** (elk met zijn eigen GVL/interpreter) — `fork`, de `parallel` gem, of meerdere worker-processen (hoe Rails-servers zoals Puma schalen).

## Moderne concurrency-tools

```text
✓ Ractors (Ruby 3) — actor-model parallelism that CAN run Ruby in parallel (no shared GVL
  per Ractor) — experimental, true parallelism
✓ Fibers / async gem — lightweight cooperative concurrency for high-I/O workloads
✓ Background jobs (Sidekiq) — offload work to separate worker processes
Note: alternative Ruby implementations (JRuby, TruffleRuby) have NO GVL → true thread parallelism
```

## Waarom het belangrijk is

Het begrijpen van de GVL en Ruby-concurrency is belangrijk — en vaak verkeerd begrepen — kennis voor het bouwen van performante Ruby-applicaties, net als de GIL-situatie in Python.

De kerngedachte is dat de **GVL van MRI Ruby slechts één thread toestaat om Ruby-code tegelijk uit te voeren**, dus threads bieden *geen* CPU-parallelisme — een veel voorkomend punt van verwarring.

Kritisch is dat de GVL **wordt vrijgegeven tijdens I/O**, wat betekent dat de juiste concurrency-benadering afhangt van de workload: **threads werken goed voor I/O-gebonden taken** (netwerkoproepen, bestand-/databasetoegang — waar de GVL wordt vrijgegeven tijdens wachten, waardoor threads kunnen overlappen), maar **CPU-gebonden parallelisme vereist meerdere processen** (elk met zijn eigen GVL, echte parallelisme over cores bereikt — via `fork`, de `parallel` gem, of meerdere worker-processen, wat hoe Rails-servers schalen).

Misverstand over de GVL leidt tot ineffectieve concurrency-code (bijvoorbeeld het gebruik van threads voor CPU-intensief werk met verwachting van versnelling).

Het kennen van de I/O-versus-CPU-beslissing (threads voor I/O-concurrency, processen voor CPU-parallelisme), moderne tools (Ractors voor experimenteel echt parallelisme, Fibers/async voor hoog-I/O coöperatieve concurrency, background job-processors zoals Sidekiq), en dat alternatieve implementaties (JRuby, TruffleRuby) geen GVL hebben, is belangrijk voor het schrijven van concurrente Ruby die daadwerkelijk presteert.

Aangezien concurrency een veelvoorkomende behoefte is en de GVL fundamenteel de juiste benadering bepaalt, is het begrijpen ervan — waarom threads CPU-werk niet paralleliseren, dat ze helpen voor I/O, en dat processen nodig zijn voor CPU-parallelisme — belangrijk kennis op senior level dat een veel voorkomende fout voorkomt en een veelvoorkomend interview-onderwerp is dat het begrip van Ruby's concurrency-model en zijn GVL-beperking weerspiegelt.

De GVL: één thread voert Ruby-code tegelijk uit

Threads — goed voor I/O-gebonden concurrency

Processen — voor CPU-gebonden parallelisme

Moderne concurrency-tools

Waarom het belangrijk is

Gerelateerde vragen