Hva er GVL og hvordan fungerer concurrency i Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, tidligere GIL) i MRI Ruby tillater kun **én tråd å kjøre Ruby-kode om gangen** — så tråder gir ikke ekte CPU-parallellisme. Men GVL blir **frigitt under I/O**, så tråder *hjelper* faktisk for I/O-bound arbeid. For CPU-parallellisme bruker du flere prosesser. Dette speiler Pythons GIL-situasjon.

## GVL: én tråd kjører Ruby-kode om 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åder — bra for I/O-bound 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åder hjelper for I/O-bound arbeid (nettverk, fil, database) fordi GVL blir frigitt under ventetiden, slik at andre tråder kan kjøre. De fremskynder **ikke** CPU-bound arbeid (GVL serialiserer Ruby-kjøring).

## Prosesser — for CPU-bound parallellisme

```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-bound parallellisme bruker du **flere prosesser** (hver med sin egen GVL/tolker) — `fork`, `parallel`-gemaet, eller kjøring av flere arbeiderprosesser (hvordan Rails-servere som Puma skaleres).

## Moderne concurrency-verktøy

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

Å forstå GVL og Ruby-concurrency er viktig — og ofte misforstått — kunnskap for å bygge performante Ruby-applikasjoner, på samme måte som Pythons GIL-situasjon.

Hovedinsikten er at MRI Rubys **GVL tillater kun én tråd å kjøre Ruby-kode om gangen**, så tråder gir *ikke* CPU-parallellisme — et vanlig misforståelsespunkt.

Kritisk sett blir GVL **frigitt under I/O**, noe som betyr at riktig concurrency-tilnærming avhenger av arbeidsbelastningen: **tråder fungerer godt for I/O-bound oppgaver** (nettverksanrop, fil/databasetilgang — hvor GVL blir frigitt under ventetider, slik at tråder kan overlappe), men **CPU-bound parallellisme krever flere prosesser** (hver med sin egen GVL, oppnår ekte parallellisme på tvers av kjerner — via `fork`, `parallel`-gemaet, eller flere arbeiderprosesser, som er hvordan Rails-servere skaleres).

Misforståelse av GVL fører til ineffektiv concurrency-kode (f.eks. bruk av tråder for CPU-tung arbeid i håp om raskere kjøring).

Å kjenne I/O-vs-CPU-beslutningen (tråder for I/O-concurrency, prosesser for CPU-parallellisme), moderne verktøy (Ractors for eksperimentell ekte parallellisme, Fibers/async for høy-I/O samarbeidende concurrency, bakgrunnsjobb-prosessorer som Sidekiq), og at alternative implementasjoner (JRuby, TruffleRuby) mangler GVL er viktig for å skrive concurrent Ruby som faktisk performet.

Fordi concurrency er et vanlig behov og GVL fundamentalt former riktig tilnærming, å forstå det — hvorfor tråder ikke parallelliserer CPU-arbeid, at de hjelper for I/O, og at prosesser er nødvendig for CPU-parallellisme — er viktig senior-nivå kunnskap som forhindrer en hyppig feil og er et vanlig intervjuemne som gjenspeiler forståelse av Rubys concurrency-modell og dens GVL-begrensning.