GVL کیا ہے اور Ruby میں concurrency کیسے کام کرتی ہے؟

Question

IT Interview Practice · Accepted Answer

**GVL** (Global VM Lock، پہلے GIL کے نام سے جانا جاتا تھا) MRI Ruby میں صرف **ایک thread کو ایک وقت میں Ruby code کو execute کرنے کی اجازت دیتا ہے** — تو threads اصل میں CPU parallelism فراہم نہیں کرتے۔ لیکن GVL **I/O کے دوران release ہوتا ہے**، تو threads *دراصل* I/O-bound کام کے لیے مدد کرتے ہیں۔ CPU parallelism کے لیے، آپ متعدد processes استعمال کرتے ہیں۔ یہ Python کی GIL صورتحال کی عکاسی کرتا ہے۔

## 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 انتظار کے دوران release ہوتا ہے، دوسرے threads کو چلنے دیتا ہے۔ وہ CPU-bound کام کو تیز **نہیں** کرتے (GVL Ruby کی execution کو sequence میں رکھتا ہے)۔

## 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 کے لیے، **متعدد processes** استعمال کریں (ہر ایک کے اپنے GVL/interpreter کے ساتھ) — `fork`، `parallel` gem، یا متعدد worker processes چلانا (جیسے Rails servers جیسے Puma 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 کو سمجھنا اہم ہے — اور اکثر غلط سمجھا جاتا ہے — Ruby کی کارکردگی والی applications بنانے کے لیے ضروری علم، Python کی GIL صورتحال کی طرح۔

اہم نکتہ یہ ہے کہ MRI Ruby کا **GVL صرف ایک thread کو ایک وقت میں Ruby code execute کرنے دیتا ہے**، تو threads CPU parallelism *فراہم نہیں کرتے* — confusion کا عام نقطہ۔

اہم بات یہ ہے کہ GVL **I/O کے دوران release ہوتا ہے**، جس کا مطلب ہے کہ صحیح concurrency approach workload پر منحصر ہے: **threads I/O-bound tasks کے لیے اچھی طرح کام کرتے ہیں** (network calls، file/database access — جہاں GVL انتظار کے دوران release ہوتا ہے، threads کو overlap کرنے دیتا ہے)، لیکن **CPU-bound parallelism کے لیے متعدد processes ضروری ہیں** (ہر ایک کے اپنے GVL کے ساتھ، cores میں اصل parallelism حاصل کرتے ہوئے — `fork`، `parallel` gem، یا متعدد worker processes کے ذریعے، جو Rails servers scale کرتے ہیں)۔

GVL کو غلط سمجھنا غیر مؤثر concurrency code کی طرف لے جاتا ہے (جیسے CPU-heavy کام کے لیے threads استعمال کرنا جو speedup کی توقع کرتے ہوں)۔

I/O-vs-CPU decision (I/O concurrency کے لیے threads، CPU parallelism کے لیے processes) کو جاننا، جدید tools (Ractors experimental true parallelism کے لیے، Fibers/async high-I/O cooperative concurrency کے لیے، Sidekiq جیسے background job processors)، اور یہ کہ متبادل implementations (JRuby، TruffleRuby) میں GVL نہیں ہے، concurrent Ruby لکھنے کے لیے اہم ہے جو اصل میں کارکردگی دیتا ہے۔

چونکہ concurrency ایک عام ضرورت ہے اور GVL بنیادی طور پر صحیح approach کو شکل دیتا ہے، اسے سمجھنا — کہ threads CPU کام کو parallelise نہیں کرتے، کہ وہ I/O میں مدد کرتے ہیں، اور CPU parallelism کے لیے processes ضروری ہیں — اہم senior-level علم ہے جو ایک عام غلطی سے روکتا ہے اور Ruby کی concurrency model اور اس کی GVL پابندی کی سمجھ کو ظاہر کرتے ہوئے ایک عام interview موضوع ہے۔

GVL: ایک وقت میں ایک thread Ruby code چلاتا ہے

Threads — I/O-bound concurrency کے لیے اچھے

Processes — CPU-bound parallelism کے لیے

جدید concurrency tools

یہ کیوں اہم ہے

متعلقہ سوالات