GVL কী এবং Ruby-তে concurrency কিভাবে কাজ করে?

Question

Accepted Answer

**GVL** (Global VM Lock, পূর্বে GIL) MRI Ruby-তে একবারে শুধুমাত্র **একটি thread Ruby কোড execute করতে পারে** — তাই threads সত্যিকারের CPU parallelism প্রদান করে না। কিন্তু GVL **I/O-এর সময় release হয়**, তাই threads *সত্যিই* I/O-bound কাজের জন্য সাহায্য করে। CPU parallelism-এর জন্য, আপনি multiple processes ব্যবহার করেন। এটি Python-এর GIL পরিস্থিতি প্রতিফলিত করে।

## GVL: একবারে একটি thread Ruby কোড run করে

```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-কে run করতে দেয়। তারা CPU-bound কাজ (GVL Ruby execution serialize করে) **করে না** speedup।

## 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 চালান (কিভাবে 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 বোঝা গুরুত্বপূর্ণ — এবং প্রায়শই ভুল বোঝা — জ্ঞান performant Ruby applications তৈরি করার জন্য, Python-এর GIL পরিস্থিতির মতো।

মূল insight হল যে MRI Ruby-এর **GVL একবারে শুধুমাত্র একটি thread-কে Ruby কোড execute করতে দেয়**, তাই threads CPU parallelism প্রদান *করে না* — এটি বিভ্রান্তির একটি সাধারণ বিন্দু।

সমালোচনামূলকভাবে, GVL **I/O-এর সময় release হয়**, যার মানে সঠিক concurrency পদ্ধতি workload-এর উপর নির্ভর করে: **threads I/O-bound tasks-এর জন্য ভাল কাজ করে** (network calls, file/database access — যেখানে GVL waits-এর সময় release হয়, threads overlap-কে যেতে দেয়), কিন্তু **CPU-bound parallelism একাধিক processes প্রয়োজন** (প্রতিটির নিজস্ব GVL, cores জুড়ে সত্যিকারের parallelism অর্জন করে — `fork`, `parallel` gem, অথবা multiple worker processes এর মাধ্যমে, যা কিভাবে Rails servers scale করে)।

GVL ভুল বোঝা অকার্যকর concurrency কোডের দিকে পরিচালিত করে (যেমন 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 লেখার জন্য গুরুত্বপূর্ণ যা সত্যিকার পারফর্ম করে।

Concurrency একটি সাধারণ প্রয়োজন হওয়া এবং GVL মৌলিকভাবে সঠিক পদ্ধতি গঠন করা হওয়ার কারণে, এটি বোঝা — কেন threads CPU কাজ parallelize করে না, যে তারা I/O-এর জন্য সাহায্য করে, এবং যে processes CPU parallelism-এর জন্য প্রয়োজন — গুরুত্বপূর্ণ senior-level জ্ঞান যা একটি ঘন ঘন ভুল প্রতিরোধ করে এবং Ruby-এর concurrency মডেল এবং এর GVL constraint-এর বোঝাপড়া প্রতিফলিত করে একটি সাধারণ interview বিষয়।