Ce este GVL și cum funcționează concurența în Ruby?

Question

Accepted Answer

**GVL**-ul (Global VM Lock, cunoscut anterior drept GIL) în MRI Ruby permite doar **unui singur thread să execute cod Ruby la un moment dat** — deci threadurile nu oferă adevărat paralelism pe CPU. Însă GVL-ul este **eliberat în timp de I/O**, deci threadurile *ajută* pentru lucrul I/O-bound. Pentru paralelism pe CPU, folosești mai multe procese. Aceasta reflectă situația GIL-ului din Python.

## GVL-ul: un singur thread execută cod Ruby la un moment dat

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

## Threaduri — bune pentru concurență I/O-bound

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

Threadurile ajută pentru lucrul I/O-bound (rețea, fișier, bază de date) deoarece GVL-ul este eliberat în timp de așteptare, permițând altor threaduri să ruleze. Ele **nu** accelerează lucrul CPU-bound (GVL-ul serializează execuția Ruby).

## Procese — pentru paralelism CPU-bound

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

Pentru paralelism CPU-bound, folosește **mai multe procese** (fiecare cu propriul său GVL/interpret) — `fork`, gemul `parallel`, sau rularea mai multor procese worker (modul în care servere Rails ca Puma se extind).

## Instrumente moderne de concurență

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

## De ce este important

Înțelegerea GVL-ului și a concurenței în Ruby este cunoaștere importantă — și frecvent înțeles greșit — pentru construirea aplicațiilor Ruby performante, similar cu situația GIL-ului din Python.

Insight-ul cheie este că **GVL-ul Ruby MRI permite doar unui singur thread să execute cod Ruby la un moment dat**, deci threadurile **nu** oferă paralelism pe CPU — un punct frecvent de confuzie.

Critic, GVL-ul este **eliberat în timp de I/O**, ceea ce înseamnă că abordarea corectă a concurenței depinde de sarcină: **threadurile funcționează bine pentru sarcini I/O-bound** (apeluri de rețea, acces la fișiere/baze de date — unde GVL-ul este eliberat în timp de așteptări, permitând threadurilor să se suprapună), dar **paralelismul CPU-bound necesită mai multe procese** (fiecare cu propriul GVL, realizând adevărat paralelism pe mai multe nuclee — prin `fork`, gemul `parallel`, sau mai multe procese worker, ceea ce este modul în care servere Rails se extind).

Neînțelegerea GVL-ului duce la cod de concurență ineficient (de ex. folosirea threadurilor pentru lucrul CPU-greu așteptând accelerare).

Cunoașterea deciziei I/O-vs-CPU (threaduri pentru concurență I/O, procese pentru paralelism CPU), a instrumentelor moderne (Ractors pentru paralelism adevărat experimental, Fibers/async pentru concurență cooperativă I/O-intensivă, procesoare de lucrări din spate ca Sidekiq), și că implementări alternative (JRuby, TruffleRuby) nu au GVL-ul este importantă pentru scrierea concurenței Ruby care chiar funcționează.

Deoarece concurența este o nevoie comună și GVL-ul modelează fundamental abordarea corectă, înțelegerea acestuia — de ce threadurile nu paralelizează lucrul pe CPU, că ajută pentru I/O, și că procesele sunt necesare pentru paralelism CPU — este cunoaștere importantă la nivel senior care previne o greșeală frecventă și este un subiect comun de interviu reflectând înțelegerea modelului de concurență al Ruby-ului și constrângerea GVL-ului.