Apa itu GVL dan bagaimana concurrency bekerja di Ruby?

Question

Accepted Answer

**GVL** (Global VM Lock, dulunya GIL) dalam MRI Ruby memungkinkan hanya **satu thread untuk menjalankan kode Ruby pada satu waktu** — jadi thread tidak menyediakan true CPU parallelism. Namun GVL **dilepaskan selama I/O**, jadi thread *memang* membantu untuk pekerjaan I/O-bound. Untuk CPU parallelism, Anda menggunakan multiple processes. Ini mencerminkan situasi GIL milik Python.

## GVL: satu thread menjalankan kode Ruby pada satu waktu

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

## Thread — bagus untuk concurrency 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
```

Thread membantu untuk pekerjaan I/O-bound (network, file, DB) karena GVL dilepaskan selama menunggu, membiarkan thread lain berjalan. Mereka **tidak** mempercepat pekerjaan CPU-bound (GVL menserialisasi eksekusi Ruby).

## Process — untuk 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
```

Untuk CPU-bound parallelism, gunakan **multiple processes** (masing-masing dengan GVL/interpreter-nya sendiri) — `fork`, gem `parallel`, atau menjalankan multiple worker processes (bagaimana Rails servers seperti 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
```

## Mengapa ini penting

Memahami GVL dan Ruby concurrency adalah pengetahuan yang penting — dan sering disalahpahami — untuk membangun Ruby applications yang performan, mirip dengan situasi GIL milik Python.

Insight kunci adalah bahwa GVL Ruby MRI **memungkinkan hanya satu thread untuk menjalankan kode Ruby pada satu waktu**, jadi thread **tidak** menyediakan CPU parallelism — ini adalah titik kebingungan yang umum.

Yang kritis, GVL **dilepaskan selama I/O**, yang berarti pendekatan concurrency yang tepat tergantung pada workload: **thread bekerja dengan baik untuk tugas I/O-bound** (network calls, akses file/database — di mana GVL dilepaskan selama waits, membiarkan thread overlap), tetapi **CPU-bound parallelism memerlukan multiple processes** (masing-masing dengan GVL-nya sendiri, mencapai true parallelism across cores — via `fork`, gem `parallel`, atau multiple worker processes, yang merupakan bagaimana Rails servers scale).

Misunderstanding GVL mengarah ke kode concurrency yang tidak efektif (misalnya menggunakan thread untuk pekerjaan CPU-heavy mengharapkan speedup).

Mengetahui keputusan I/O-vs-CPU (thread untuk I/O concurrency, process untuk CPU parallelism), modern tools (Ractor untuk experimental true parallelism, Fiber/async untuk cooperative concurrency high-I/O, background job processors seperti Sidekiq), dan bahwa alternative implementations (JRuby, TruffleRuby) tidak memiliki GVL adalah penting untuk menulis concurrent Ruby yang benar-benar perform.

Karena concurrency adalah kebutuhan umum dan GVL secara fundamental membentuk pendekatan yang tepat, memahaminya — mengapa thread tidak parallelize CPU work, bahwa mereka membantu untuk I/O, dan bahwa process dibutuhkan untuk CPU parallelism — adalah pengetahuan senior-level yang penting yang mencegah kesalahan yang sering terjadi dan merupakan topik interview umum yang mencerminkan pemahaman tentang model concurrency Ruby dan constraints GVL-nya.