What is the GVL and how does concurrency work in Ruby?

Question

Accepted Answer

The **GVL** (Global VM Lock, formerly GIL) in MRI Ruby allows only **one thread to execute Ruby code at a time** — so threads don't provide true CPU parallelism. But the GVL is **released during I/O**, so threads *do* help for I/O-bound work. For CPU parallelism, you use multiple processes. This mirrors Python's GIL situation.

## The GVL: one thread runs Ruby code at a time

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

## Threads — good for I/O-bound concurrency

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

Threads help for I/O-bound work (network, file, DB) because the GVL is released during the wait, letting other threads run. They do **not** speed up CPU-bound work (the GVL serializes Ruby execution).

## Processes — for CPU-bound parallelism

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

For CPU-bound parallelism, use **multiple processes** (each with its own GVL/interpreter) — `fork`, the `parallel` gem, or running multiple worker processes (how Rails servers like Puma scale).

## Modern concurrency tools

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

## Why it matters

Understanding the GVL and Ruby concurrency is important — and frequently misunderstood — knowledge for building performant Ruby applications, much like Python's GIL situation.

The key insight is that MRI Ruby's **GVL allows only one thread to execute Ruby code at a time**, so threads do *not* provide CPU parallelism — a common point of confusion.

Critically, the GVL is **released during I/O**, which means the correct concurrency approach depends on the workload: **threads work well for I/O-bound tasks** (network calls, file/database access — where the GVL is released during waits, letting threads overlap), but **CPU-bound parallelism requires multiple processes** (each with its own GVL, achieving true parallelism across cores — via `fork`, the `parallel` gem, or multiple worker processes, which is how Rails servers scale).

Misunderstanding the GVL leads to ineffective concurrency code (e.g. using threads for CPU-heavy work expecting speedup).

Knowing the I/O-vs-CPU decision (threads for I/O concurrency, processes for CPU parallelism), modern tools (Ractors for experimental true parallelism, Fibers/async for high-I/O cooperative concurrency, background job processors like Sidekiq), and that alternative implementations (JRuby, TruffleRuby) lack the GVL is important for writing concurrent Ruby that actually performs.

Since concurrency is a common need and the GVL fundamentally shapes the right approach, understanding it — why threads don't parallelize CPU work, that they help for I/O, and that processes are needed for CPU parallelism — is important senior-level knowledge that prevents a frequent mistake and is a common interview topic reflecting understanding of Ruby's concurrency model and its GVL constraint.