Hvad er GVL, og hvordan fungerer concurrency i Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, tidligere GIL) i MRI Ruby tillader kun **én tråd at udføre Ruby-kode ad gangen** — så tråde giver ikke ægte CPU-parallelisme. Men GVL **frigives under I/O**, så tråde *hjælper* faktisk med I/O-bundet arbejde. For CPU-parallelisme bruger du flere processer. Dette svarer til Pythons GIL-situation.

## GVL: én tråd kører Ruby-kode ad gangen

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

## Tråde — godt til I/O-bundet 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
```

Tråde hjælper med I/O-bundet arbejde (netværk, fil, DB), fordi GVL frigives under ventetiden, hvilket lader andre tråde køre. De **gør ikke** CPU-bundet arbejde hurtigere (GVL serialiserer Ruby-udførelse).

## Processer — til CPU-bundet 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
```

For CPU-bundet parallelisme bruger du **flere processer** (hver med sin egen GVL/interpreter) — `fork`, `parallel`-gemmen, eller kørende multiple worker-processer (hvordan Rails-servere som Puma skaleres).

## Moderne concurrency-værktøjer

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

## Hvorfor det betyder noget

At forstå GVL og Ruby-concurrency er vigtig — og ofte misforstået — viden for at bygge performante Ruby-applikationer, meget ligesom Pythons GIL-situation.

Hovedindlægget er, at MRI Rubys **GVL tillader kun én tråd at udføre Ruby-kode ad gangen**, så tråde giver *ikke* CPU-parallelisme — et almindeligt misforståelses-punkt.

Kritisk set **frigives GVL under I/O**, hvilket betyder, at den korrekte concurrency-tilgang afhænger af arbejdsbelastningen: **tråde fungerer godt til I/O-bundne opgaver** (netværkskald, fil-/databaseadgang — hvor GVL frigives under ventetider, hvilket lader tråde overlappe), men **CPU-bundet parallelisme kræver flere processer** (hver med sin egen GVL, hvilket opnår ægte parallelisme på tværs af kerner — via `fork`, `parallel`-gemmen, eller multiple worker-processer, som er det, Rails-servere skaleres med).

Misforståelse af GVL fører til ineffektiv concurrency-kode (f.eks. brug af tråde til CPU-tungt arbejde i forventning om speedup).

At kende I/O-vs-CPU-beslutningen (tråde til I/O-concurrency, processer til CPU-parallelisme), moderne værktøjer (Ractors til eksperimentel ægte parallelisme, Fibers/async til høj-I/O kooperativ concurrency, baggrundsjob-processorer som Sidekiq), og at alternative implementeringer (JRuby, TruffleRuby) mangler GVL, er vigtig for at skrive concurrent Ruby, der faktisk performer.

Da concurrency er et almindeligt behov, og GVL fundamentalt former den rigtige tilgang, er det at forstå det — hvorfor tråde ikke paralleliserer CPU-arbejde, at de hjælper med I/O, og at processer er nødvendige til CPU-parallelisme — vigtig senior-level viden, der forebygger en hyppig fejl, og er et almindeligt interviewemne, der afspejler forståelse af Rubys concurrency-model og dets GVL-begrænsning.