Qu'est-ce que le GVL et comment fonctionne la concurrence en Ruby ?

Question

Accepted Answer

Le **GVL** (Global VM Lock, anciennement GIL) dans MRI Ruby permet à **un seul thread d'exécuter du code Ruby à la fois** — les threads ne fournissent donc pas un vrai parallélisme CPU. Mais le GVL est **libéré pendant les E/S**, les threads *aident* donc pour les tâches liées aux E/S. Pour le parallélisme CPU, vous utilisez plusieurs processus. Cela reflète la situation du GIL de Python.

## Le GVL : un seul thread exécute du code Ruby à la fois

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

## Les threads — bons pour la concurrence liée aux E/S

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

Les threads aident pour les tâches liées aux E/S (réseau, fichier, BD) car le GVL est libéré pendant l'attente, permettant à d'autres threads de s'exécuter. Ils **n'accélèrent pas** le travail lié au CPU (le GVL sérialise l'exécution Ruby).

## Les processus — pour le parallélisme lié au 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
```

Pour le parallélisme lié au CPU, utilisez **plusieurs processus** (chacun avec son propre GVL/interpréteur) — `fork`, la gem `parallel`, ou l'exécution de plusieurs processus workers (comment les serveurs Rails comme Puma se mettent à l'échelle).

## Outils de concurrence modernes

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

## Pourquoi c'est important

Comprendre le GVL et la concurrence en Ruby est une connaissance importante — et fréquemment mal comprise — pour construire des applications Ruby performantes, tout comme la situation du GIL de Python.

L'idée clé est que le **GVL de MRI Ruby permet à un seul thread d'exécuter du code Ruby à la fois**, les threads ne fournissent donc *pas* de parallélisme CPU — un point de confusion courant.

Critiquement, le GVL est **libéré pendant les E/S**, ce qui signifie que l'approche de concurrence correcte dépend de la charge de travail : **les threads fonctionnent bien pour les tâches liées aux E/S** (appels réseau, accès fichier/base de données — où le GVL est libéré pendant les attentes, permettant aux threads de se chevaucher), mais **le parallélisme lié au CPU nécessite plusieurs processus** (chacun avec son propre GVL, réalisant un vrai parallélisme sur les cœurs — via `fork`, la gem `parallel`, ou plusieurs processus workers, c'est comme les serveurs Rails se mettent à l'échelle).

Mal comprendre le GVL mène à du code de concurrence inefficace (par exemple, utiliser les threads pour le travail lourd du CPU en s'attendant à une accélération).

Connaître la décision E/S-vs-CPU (threads pour la concurrence E/S, processus pour le parallélisme CPU), les outils modernes (Ractors pour le vrai parallélisme expérimental, Fibers/async pour la concurrence coopérative haute-E/S, les processeurs de tâches en arrière-plan comme Sidekiq), et que les implémentations alternatives (JRuby, TruffleRuby) n'ont pas le GVL est important pour écrire de la concurrence Ruby qui performe réellement.

Comme la concurrence est un besoin courant et que le GVL façonne fondamentalement la bonne approche, la comprendre — pourquoi les threads ne parallélisent pas le travail CPU, qu'ils aident pour les E/S, et que les processus sont nécessaires pour le parallélisme CPU — est une connaissance importante de niveau senior qui prévient une erreur fréquente et est un sujet courant en entretien reflétant la compréhension du modèle de concurrence de Ruby et sa contrainte GVL.