Co je GVL a jak funguje souběžnost v Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, dříve GIL) v MRI Ruby umožňuje **najednou spustit pouze jedno vlákno kódu Ruby** — vlákna tedy neposkytují skutečný paralelismus CPU. Ale GVL je **uvolněn během I/O**, takže vlákna *pomohou* pro I/O-vázanou práci. Pro paralelismus CPU používáte více procesů. To se zrcadlí v situaci Pythonu s GIL.

## GVL: jedno vlákno spouští kód Ruby najednou

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

## Vlákna — dobrá pro I/O-vázanou souběžnost

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

Vlákna pomáhají při I/O-vázané práci (síť, soubor, DB), protože je GVL uvolněn během čekání, což umožňuje ostatním vláknům běžet. **Neurychlují** CPU-vázanou práci (GVL serializuje spouštění Ruby).

## Procesy — pro paralelismus vázaný na CPU

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

Pro paralelismus vázaný na CPU používejte **více procesů** (každý se svým vlastním GVL/interpretem) — `fork`, gem `parallel`, nebo spuštění více worker procesů (jak servery jako Puma škálují Rails).

## Moderní nástroje souběžnosti

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

## Proč je to důležité

Rozebrání GVL a souběžnosti Ruby je důležité — a často špatně chápané — znalosti pro vytváření výkonných Ruby aplikací, podobně jako situace GIL v Pythonu.

Klíčovým poznatkem je, že **GVL v MRI Ruby umožňuje najednou spustit pouze jedno vlákno kódu Ruby**, takže vlákna *neposkytují* paralelismus CPU — běžný zdroj zmatku.

Kriticky je GVL **uvolněn během I/O**, což znamená, že správný přístup souběžnosti závisí na zatížení: **vlákna fungují dobře pro I/O-vázané úkoly** (síťová volání, přístup k souborům/databázím — kde je GVL uvolněn během čekání, což umožňuje vláknům se překrývat), ale **paralelismus vázaný na CPU vyžaduje více procesů** (každý se svým vlastním GVL, dosahující skutečného paralelismu mezi jádry — přes `fork`, gem `parallel`, nebo více worker procesů, což je způsob, jak Rails servery škálují).

Neporozumění GVL vede k neefektivnímu kódu souběžnosti (například použití vláken pro CPU-náročnou práci s očekáváním urychlení).

Znalost rozhodnutí I/O-vs-CPU (vlákna pro I/O souběžnost, procesy pro paralelismus CPU), moderních nástrojů (Ractors pro experimentální skutečný paralelismus, Fibers/async pro vysoce-I/O kooperativní souběžnost, background job procesory jako Sidekiq) a že alternativní implementace (JRuby, TruffleRuby) nemají GVL, je důležité pro psaní souběžného Ruby, které skutečně funguje.

Jelikož je souběžnost časté požadavkem a GVL zásadně utváří správný přístup, jeho porozumění — proč vlákna nezvyšují paralelismus CPU práce, že pomáhají pro I/O, a že procesy jsou potřebné pro paralelismus CPU — je důležitá znalost na úrovni seniorů, která zabraňuje časté chybě a je běžným tématem pohovoru odrážejícím porozumění modelu souběžnosti Ruby a jeho omezením GVL.