GVL म्हणजे काय आणि Ruby मध्ये concurrency कसे कार्य करते?

Question

Accepted Answer

**GVL** (Global VM Lock, यापूर्वी GIL) MRI Ruby मध्ये **एकावेळी फक्त एक thread Ruby code execute करू शकतो** — त्यामुळे threads true CPU parallelism प्रदान करत नाहीत. परंतु GVL **I/O दरम्यान release** होती, त्यामुळे threads *I/O-bound* कार्यसाठी मदत करतात. CPU parallelism साठी, तुम्ही multiple processes वापराल. हे Python च्या GIL परिस्थितीला mirrors करते.

## GVL: एकावेळी एक thread Ruby code चालवतो

```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 — 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 I/O-bound कार्यासाठी मदत करतात (network, file, DB) कारण GVL wait दरम्यान release होती, इतर threads चालू होऊ शकतात. ते CPU-bound कार्याला गती देत नाहीत (GVL Ruby execution serialize करते).

## Processes — 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
```

CPU-bound parallelism साठी, **multiple processes** (प्रत्येकाचा स्वतःचा GVL/interpreter) वापरा — `fork`, `parallel` gem, किंवा multiple worker processes (Puma सारख्या Rails servers कसे scale करतात).

## आधुनिक 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
```

## हे का महत्त्वपूर्ण आहे

GVL आणि Ruby concurrency समजून घेणे महत्त्वपूर्ण — आणि बर्
eचदा गलत समजलेले — performant Ruby applications बांधण्यासाठी ज्ञान, Python च्या GIL परिस्थितीप्रमाणे.

मुख्य अंतर्दृष्टी अशी आहे की MRI Ruby च्या **GVL एकावेळी फक्त एक thread Ruby code execute करू शकते**, त्यामुळे threads CPU parallelism प्रदान करत नाहीत — एक सामान्य गोंधळाचा बिंदू.

ंवलत, GVL **I/O दरम्यान release** होती, म्हणून योग्य concurrency approach workload वर अवलंबून असते: **I/O-bound tasks साठी threads चांगले काम करतात** (network calls, file/database access — जिथे GVL waits दरम्यान release होती, threads overlap करू शकतात), परंतु **CPU-bound parallelism साठी multiple processes आवश्यक आहेत** (प्रत्येकाचा स्वतःचा GVL, cores भोवती true parallelism साध्य करते — `fork`, `parallel` gem, किंवा multiple worker processes द्वारे, जे Rails servers कसे scale करतात).

GVL समजून न घेतल्यास ineffective concurrency code तयार होते (उदा. CPU-heavy कार्यासाठी threads वापरून speedup अपेक्षा करणे).

I/O-vs-CPU निर्णय (I/O concurrency साठी threads, CPU parallelism साठी processes), आधुनिक tools (experimental true parallelism साठी Ractors, high-I/O cooperative concurrency साठी Fibers/async, Sidekiq सारख्या background job processors), आणि alternative implementations (JRuby, TruffleRuby) ज्यांना GVL नाही, हे जाणून घेणे concurrent Ruby लिहिण्यासाठी महत्त्वपूर्ण आहे जे खरोखर perform करते.

Concurrency एक सामान्य गरज असल्यामुळे आणि GVL मूलतः योग्य approach आकार देते, हे समजून घेणे — threads का CPU कार्य parallelize करत नाहीत, ते I/O साठी मदत करतात, आणि CPU parallelism साठी processes आवश्यक आहेत — हे महत्त्वपूर्ण senior-level ज्ञान आहे जे एक सामान्य चूक रोखते आणि Ruby च्या concurrency model आणि त्याच्या GVL constraint समजून घेणे प्रतिबिंबित करणारा सामान्य interview topic आहे.