GVL ਕੀ ਹੈ ਅਤੇ Ruby ਵਿੱਚ concurrency ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?

Question

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 ਸਥਿਤੀ ਨੂੰ mirror ਕਰਦਾ ਹੈ।

## 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 ਲਈ, **ਕਈ processes ਵਰਤੋ** (ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ GVL/interpreter) — `fork`, `parallel` gem, ਜਾਂ ਕਈ 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 ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ — ਅਤੇ ਅਕਸਰ ਗਲਤਫਹਮੀ ਵਾਲਾ — ਪ੍ਰਭਾਵਸ਼ਾਲੀ Ruby ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਗਿਆਨ ਹੈ, Python ਦੀ GIL ਸਥਿਤੀ ਦੀ ਤਰ੍ਹਾਂ।

ਮੁੱਖ insight ਇਹ ਹੈ ਕਿ MRI Ruby ਦਾ **GVL ਸਿਰਫ ਇੱਕ thread ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ Ruby code ਚਲਾਉਣ ਦਿੰਦਾ ਹੈ**, ਇਸ ਲਈ threads **CPU parallelism ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ** — ਇੱਕ ਆਮ confusion ਦਾ ਬਿੰਦੂ।

ਨਾਜ਼ੁਕ ਤੌਰ 'ਤੇ, GVL **I/O ਦੇ ਦੌਰਾਨ release ਹੋ ਜਾਂਦਾ ਹੈ**, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਹੀ concurrency approach 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, ਜਾਂ ਕਈ worker processes ਦੁਆਰਾ, ਜੋ Rails servers scale ਕਿਵੇਂ ਕਰਦੇ ਹਨ)।

GVL ਨੂੰ ਗਲਤ ਸਮਝਣਾ ਅਪ੍ਰਭਾਵਸ਼ਾਲੀ concurrency code ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ speedup ਦੀ ਉਮੀਦ ਵਿੱਚ CPU-heavy ਕੰਮ ਲਈ threads ਵਰਤਣਾ)।

I/O-vs-CPU ਫੈਸਲਾ ਜਾਣਨਾ (I/O concurrency ਲਈ threads, CPU parallelism ਲਈ processes), ਆਧੁਨਿਕ tools (ਪ੍ਰਯੋਗੀ ਸਚਮੁਚ parallelism ਲਈ Ractors, ਉੱਚ-I/O cooperative concurrency ਲਈ Fibers/async, Sidekiq ਵਰਗੇ background job processors), ਅਤੇ ਇਹ ਕਿ ਵਿਕਲਪ implementations (JRuby, TruffleRuby) ਕੋਲ GVL ਨਹੀਂ ਹੈ ਮਹੱਤਵਪੂਰਨ ਹੈ concurrent Ruby ਲਿਖਣ ਲਈ ਜੋ ਅਸਲ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ।

ਕਿਉਂਕਿ concurrency ਇੱਕ ਆਮ ਲੋੜ ਹੈ ਅਤੇ GVL ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਸਹੀ approach ਨੂੰ ਆਕਾਰ ਦਿੰਦਾ ਹੈ, ਇਸਨੂੰ ਸਮਝਣਾ — ਕਿਉਂ threads CPU ਕੰਮ ਨੂੰ parallelize ਨਹੀਂ ਕਰਦੇ, ਕਿ ਉਹ I/O ਲਈ ਸਹਾਇਕ ਹਨ, ਅਤੇ ਕਿ CPU parallelism ਲਈ processes ਦੀ ਲੋੜ ਹੈ — ਸੀਨੀਅਰ-ਪੱਧਰ ਦਾ ਗਿਆਨ ਹੈ ਜੋ ਇੱਕ ਆਮ ਗਲਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਆਮ interview ਵਿਸ਼ਾ ਹੈ ਜੋ Ruby ਦੀ concurrency model ਅਤੇ ਇਸ ਦੀ GVL ਪ੍ਰਤਿਬੰਧ ਨੂੰ ਸਮਝ ਨੂੰ ਪ੍ਰਤੀਬਿੰਬਤ ਕਰਦਾ ਹੈ।