Vad är GVL och hur fungerar concurrency i Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, tidigare GIL) i MRI Ruby tillåter endast **en tråd att köra Ruby-kod åt gången** — så trådar ger inte sann CPU-parallellism. Men GVL **frigörs under I/O**, så trådar *hjälper* för I/O-bunden arbete. För CPU-parallellism använder du flera processer. Detta speglar Pythons GIL-situation.

## GVL: en tråd kör Ruby-kod åt gången

```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ådar — bra för I/O-bunden 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ådar hjälper för I/O-bundet arbete (nätverk, fil, DB) eftersom GVL frigörs under väntan, vilket låter andra trådar köra. De **påskyndar inte** CPU-bundet arbete (GVL serialiserar Ruby-exekvering).

## Processer — för CPU-bunden parallellism

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

För CPU-bunden parallellism, använd **flera processer** (var och en med sin egen GVL/interpreter) — `fork`, `parallel`-gemen, eller att köra flera worker-processer (hur Rails-servrar som Puma skaleras).

## Moderna concurrency-verktyg

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

## Varför det spelar roll

Att förstå GVL och Ruby concurrency är viktig — och ofta missförstått — kunskap för att bygga performanta Ruby-applikationer, ungefär som Pythons GIL-situation.

Huvudinsikten är att MRI Rubys **GVL bara tillåter en tråd att köra Ruby-kod åt gången**, så trådar ger *inte* CPU-parallellism — en vanlig förvirringspunkt.

Kritiskt är att GVL **frigörs under I/O**, vilket betyder att rätt concurrency-strategi beror på workload: **trådar fungerar bra för I/O-bundna uppgifter** (nätverksanrop, fil-/databasåtkomst — där GVL frigörs under väntan, vilket låter trådar överlappa), men **CPU-bunden parallellism kräver flera processer** (var och en med sin egen GVL, vilket uppnår sann parallellism över kärnor — via `fork`, `parallel`-gemen, eller flera worker-processer, vilket är hur Rails-servrar skaleras).

Missförstånd om GVL leder till ineffektiv concurrency-kod (t.ex. att använda trådar för CPU-tungt arbete och förvänta acceleration).

Att känna till I/O-vs-CPU-beslutet (trådar för I/O concurrency, processer för CPU-parallellism), moderna verktyg (Ractors för experimentell sann parallellism, Fibers/async för höga I/O-kooperativ concurrency, bakgrundsjobb-processorer som Sidekiq), och att alternativa implementeringar (JRuby, TruffleRuby) saknar GVL är viktigt för att skriva concurrency-Ruby som faktiskt presterar.

Då concurrency är ett vanligt behov och GVL fundamentalt formar rätt strategi, är det viktigt seniornivå-kunskap att förstå den — varför trådar inte parallelliserar CPU-arbete, att de hjälper för I/O, och att processer behövs för CPU-parallellism — kunskap som förhindrar ett vanligt misstag och är ett vanligt intervjuämne som reflekterar förståelse för Rubys concurrency-modell och dess GVL-begränsning.