El GVL (Global VM Lock, antes conocido como GIL) en MRI Ruby permite que solo un thread ejecute código Ruby a la vez — por lo que los threads no proporcionan paralelismo CPU verdadero. Pero el GVL se libera durante I/O, así que los threads sí ayudan para trabajo vinculado a I/O. Para paralelismo CPU, usas múltiples procesos. Esto refleja la situación del GIL de 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
Los threads ayudan para trabajo vinculado a I/O (red, archivo, DB) porque el GVL se libera durante la espera, permitiendo que otros threads se ejecuten. No aceleran trabajo vinculado a CPU (el GVL serializa la ejecución de 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
Para paralelismo vinculado a CPU, usa múltiples procesos (cada uno con su propio GVL/intérprete) — fork, la gema parallel, o ejecutar múltiples procesos worker (cómo servidores Rails como Puma escalan).
✓ 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
Comprender el GVL y la concurrencia en Ruby es conocimiento importante — y frecuentemente incomprendido — para construir aplicaciones Ruby eficientes, similar a la situación del GIL en Python.
La idea clave es que el GVL de MRI Ruby permite que solo un thread ejecute código Ruby a la vez, así que los threads no proporcionan paralelismo CPU — un punto de confusión común.
Críticamente, el GVL se libera durante I/O, lo que significa que el enfoque correcto de concurrencia depende de la carga de trabajo: los threads funcionan bien para tareas vinculadas a I/O (llamadas de red, acceso a archivo/base de datos — donde el GVL se libera durante esperas, permitiendo que los threads se solapen), pero el paralelismo vinculado a CPU requiere múltiples procesos (cada uno con su propio GVL, logrando verdadero paralelismo entre núcleos — vía fork, la gema parallel, o múltiples procesos worker, que es cómo los servidores Rails escalan).
Mal entender el GVL lleva a código de concurrencia inefectivo (ej. usar threads para trabajo CPU-intensivo esperando aceleración).
Conocer la decisión I/O-vs-CPU (threads para concurrencia I/O, procesos para paralelismo CPU), herramientas modernas (Ractors para paralelismo verdadero experimental, Fibers/async para concurrencia cooperativa con alto I/O, procesadores de trabajos en segundo plano como Sidekiq), y que implementaciones alternativas (JRuby, TruffleRuby) carecen del GVL es importante para escribir Ruby concurrente que realmente funcione.
Ya que concurrencia es una necesidad común y el GVL forma fundamentalmente el enfoque correcto, comprenderlo — por qué los threads no paralelizan trabajo CPU, que ayudan para I/O, y que los procesos son necesarios para paralelismo CPU — es conocimiento importante a nivel senior que previene un error frecuente y es un tema común de entrevista que refleja comprensión del modelo de concurrencia de Ruby y su restricción del GVL.