Il GVL (Global VM Lock, precedentemente GIL) in MRI Ruby permette l'esecuzione di un solo thread alla volta su codice Ruby — quindi i thread non forniscono vero parallelismo CPU. Ma il GVL è rilasciato durante le operazioni I/O, quindi i thread aiutano per il lavoro legato a I/O. Per il parallelismo CPU, si usano più processi. Questo rispecchia la situazione del GIL di Python.
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.
# ✅ 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
I thread aiutano per il lavoro I/O-bound (rete, file, DB) perché il GVL è rilasciato durante l'attesa, permettendo ad altri thread di eseguire. Non accelerano il lavoro CPU-bound (il GVL serializza l'esecuzione di 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
Per il parallelismo CPU-bound, usa più processi (ognuno con il proprio GVL/interprete) — fork, la gemma parallel, o l'esecuzione di più processi worker (come i server Rails come Puma scalano).
✓ 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
Comprendere il GVL e la concorrenza in Ruby è una conoscenza importante — e frequentemente fraintesa — per costruire applicazioni Ruby performanti, proprio come la situazione del GIL di Python.
L'insight chiave è che il GVL di MRI Ruby permette l'esecuzione di un solo thread su codice Ruby alla volta, quindi i thread non forniscono parallelismo CPU — un punto di confusione comune.
Criticamente, il GVL è rilasciato durante le operazioni I/O, il che significa che l'approccio di concorrenza corretto dipende dal carico di lavoro: i thread funzionano bene per i compiti I/O-bound (chiamate di rete, accesso a file/database — dove il GVL è rilasciato durante le attese, permettendo ai thread di sovrapporsi), ma il parallelismo CPU-bound richiede più processi (ognuno con il proprio GVL, raggiungendo vero parallelismo tra i core — tramite fork, la gemma parallel, o più processi worker, che è come i server Rails scalano).
Non comprendere il GVL porta a codice di concorrenza inefficace (ad es. usare thread per lavoro CPU-intensivo aspettandosi accelerazione).
Conoscere la decisione I/O-vs-CPU (thread per concorrenza I/O, processi per parallelismo CPU), gli strumenti moderni (Ractor per vero parallelismo sperimentale, Fiber/async per concorrenza cooperativa ad alto I/O, processori di job in background come Sidekiq), e che implementazioni alternative (JRuby, TruffleRuby) non hanno il GVL è importante per scrivere Ruby concorrente che sia effettivamente performante.
Poiché la concorrenza è un'esigenza comune e il GVL modella fondamentalmente l'approccio corretto, comprenderlo — perché i thread non parallelizzano il lavoro CPU, che aiutano per I/O, e che i processi sono necessari per il parallelismo CPU — è conoscenza importante di livello senior che previene un errore frequente ed è un argomento di intervista comune che riflette la comprensione del modello di concorrenza di Ruby e del suo vincolo GVL.