Czym jest GVL i jak współbieżność działa w Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, dawniej GIL) w MRI Ruby pozwala tylko **jednemu wątkowi wykonywać kod Ruby na raz** — zatem wątki nie zapewniają rzeczywistego paralelizmu CPU. Jednak GVL jest **zwalniana podczas I/O**, więc wątki *rzeczywiście* pomagają w pracy związanej z I/O. Dla paralelizmu CPU używasz wielu procesów. To odzwierciedla sytuację z GIL w Pythonie.

## GVL: jeden wątek uruchamia kod Ruby naraz

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

## Wątki — dobre dla współbieżności związanej z I/O

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

Wątki pomagają w pracy związanej z I/O (sieć, pliki, baza danych), ponieważ GVL jest zwalniana podczas oczekiwania, pozwalając innym wątkom działać. **Nie** przyspieszają pracy związanej z CPU (GVL serializuje wykonanie Ruby).

## Procesy — dla paralelizmu związanego z 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
```

Dla paralelizmu związanego z CPU używaj **wielu procesów** (każdy ze swoim GVL/interpreterem) — `fork`, gem `parallel` lub uruchomienie wielu procesów roboczych (w jaki sposób serwery Rails takie jak Puma się skalują).

## Nowoczesne narzędzia współbieżności

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

## Dlaczego to ważne

Rozumienie GVL i współbieżności w Ruby to ważna — i często źle rozumiana — wiedza do budowania wydajnych aplikacji Ruby, podobnie jak sytuacja z GIL w Pythonie.

Kluczowym spostrzeżeniem jest, że **GVL w MRI Ruby pozwala tylko jednemu wątkowi wykonywać kod Ruby naraz**, więc wątki *nie* zapewniają paralelizmu CPU — to jest częsty punkt dezorientacji.

Krytycznie, GVL jest **zwalniana podczas I/O**, co oznacza, że prawidłowe podejście do współbieżności zależy od obciążenia: **wątki działają dobrze dla zadań związanych z I/O** (wywołania sieciowe, dostęp do plików/baz danych — gdzie GVL jest zwalniana podczas oczekiwania, umożliwiając wątkom nakładanie się), ale **paralelizm związany z CPU wymaga wielu procesów** (każdy ze swoim GVL, osiągając rzeczywisty paralelizm między rdzeniami — via `fork`, gem `parallel` lub wiele procesów roboczych, w jaki sposób serwery Rails się skalują).

Brak zrozumienia GVL prowadzi do nieefektywnego kodu współbieżności (np. użycie wątków do pracy CPU-ciężkiej oczekując przyspieszenia).

Znajomość decyzji I/O-vs-CPU (wątki dla współbieżności I/O, procesy dla paralelizmu CPU), nowoczesnych narzędzi (Ractors dla eksperymentalnego rzeczywistego paralelizmu, Fibers/async dla wysokowydajnej wspólbieżności I/O, procesory zadań w tle jak Sidekiq) oraz że alternatywne implementacje (JRuby, TruffleRuby) nie mają GVL to ważna wiedza do pisania współbieżnego Ruby'ego, który rzeczywiście działa.

Ponieważ współbieżność jest powszechną potrzebą, a GVL fundamentalnie kształtuje prawidłowe podejście, zrozumienie tego — dlaczego wątki nie paralelizują pracę CPU, że pomagają dla I/O oraz że procesy są potrzebne dla paralelizmu CPU — to ważna wiedza na poziomie senior, która zapobiega częstemu błędowi i jest częstym tematem rozmowy kwalifikacyjnej odzwierciedlającym zrozumienie modelu współbieżności Ruby'ego i jego ograniczenia GVL.