MRI Ruby में GVL (Global VM Lock, पूर्व में GIL) एक समय में केवल एक thread को Ruby code execute करने की अनुमति देता है — इसलिए threads true CPU parallelism प्रदान नहीं करते। लेकिन GVL I/O के दौरान release होता है, इसलिए threads I/O-bound काम के लिए मदद करते हैं। CPU parallelism के लिए, आप multiple processes का उपयोग करते हैं। यह Python की GIL स्थिति को दर्शाता है।
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.
# ✅ 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) के लिए मदद करते हैं क्योंकि wait के दौरान GVL release होता है, जिससे अन्य threads चल सकते हैं। वे CPU-bound काम को तेज़ नहीं करते (GVL Ruby execution को serialize करता है)।
# ✅ 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 करते हैं)।
✓ 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 स्थिति की तरह।
Key insight यह है कि MRI Ruby का GVL एक समय में केवल एक thread को Ruby code execute करने की अनुमति देता है, इसलिए threads CPU parallelism प्रदान नहीं करते — confusion का एक common बिंदु।
महत्वपूर्ण रूप से, GVL I/O के दौरान release होता है, जिसका अर्थ है कि सही concurrency दृष्टिकोण workload पर निर्भर करता है: threads I/O-bound tasks के लिए अच्छी तरह काम करते हैं (network calls, file/database access — जहाँ waits के दौरान GVL release होता है, threads को overlap करने देता है), लेकिन CPU-bound parallelism के लिए multiple processes की आवश्यकता होती है (प्रत्येक का अपना GVL, cores में true parallelism प्राप्त करना — fork, parallel gem, या multiple worker processes के माध्यम से, जैसे Rails servers scale करते हैं)।
GVL को गलत समझना अप्रभावी concurrency code की ओर ले जाता है (जैसे speedup की उम्मीद में CPU-heavy काम के लिए threads का उपयोग करना)।
I/O-बनाम-CPU निर्णय (I/O concurrency के लिए threads, CPU parallelism के लिए processes), modern 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 एक common आवश्यकता है और GVL मौलिक रूप से सही दृष्टिकोण को आकार देता है, इसे समझना — threads CPU काम को parallelize क्यों नहीं करते, वे I/O के लिए क्यों मदद करते हैं, और CPU parallelism के लिए processes की आवश्यकता क्यों है — महत्वपूर्ण senior-level ज्ञान है जो एक frequent गलती को रोकता है और एक common interview topic है जो Ruby के concurrency model और इसके GVL constraint की समझ को दर्शाता है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें