GVL (Global VM Lock, eski adıyla GIL) MRI Ruby'de herhangi bir zamanda sadece bir thread'in Ruby kodunu çalıştırmasına izin verir — bu nedenle threadler gerçek CPU paralelizmini sağlamaz. Ancak GVL I/O sırasında serbest bırakılır, bu nedenle threadler gerçekten I/O-bound işler için yardımcıdır. CPU paralelizmi için birden fazla işlem (process) kullanırsınız. Bu, Python'un GIL durumunu yansıtır.
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
Threadler I/O-bound işler (ağ, dosya, DB) için yardımcıdır çünkü GVL bekleme sırasında serbest bırakılır ve diğer threadlerin çalışmasına izin verir. CPU-bound işleri hızlandırmazlar (GVL Ruby yürütmesini serileştirir).
# ✅ 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 paralelizm için birden fazla işlem kullanın (her birinin kendi GVL/interpreter'ı vardır) — fork, parallel gem'i veya birden fazla worker işlemini çalıştırarak (Puma gibi Rails sunucularının ölçeklendiği yol).
✓ 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 ve Ruby eşzamanlılığını anlamak, sık sık yanlış anlaşılan, yüksek performanslı Ruby uygulamaları oluşturmak için önemli bilgidir — Python'un GIL durumuna benzer şekilde.
Kaçırılmaması gereken temel fikir, MRI Ruby'nin GVL'sinin herhangi bir zamanda sadece bir thread'in Ruby kodunu çalıştırmasına izin vermesidir; bu nedenle threadler CPU paralelizmini sağlamaz — yaygın bir yanlış anlama noktasıdır.
Critik olarak, GVL I/O sırasında serbest bırakılır, yani doğru eşzamanlılık yaklaşımı iş yüküne bağlıdır: threadler I/O-bound görevler için iyi çalışır (ağ çağrıları, dosya/veritabanı erişimi — GVL bekleme sırasında serbest bırakıldığı yerde, threadlerin üst üste gelmesine izin verir), ancak CPU-bound paralelizm birden fazla işlem gerektirir (her birinin kendi GVL'si vardır, çekirdekler arasında gerçek paralelizm sağlar — fork, parallel gem'i veya birden fazla worker işlemi aracılığıyla, Rails sunucularının ölçeklendiği yol).
GVL'yi yanlış anlamak, etkisiz eşzamanlılık kodu oluşturur (örneğin CPU-ağır işler için hızlanma beklenerek threadler kullanmak).
I/O-vs-CPU kararını bilmek (I/O eşzamanlılığı için threadler, CPU paralelizmi için işlemler), modern araçları (deneysel gerçek paralelizm için Ractors, yüksek-I/O işbirlikçi eşzamanlılık için Fibers/async, Sidekiq gibi arka plan iş işlemcileri) ve alternatif uygulamaların (JRuby, TruffleRuby) GVL'ye sahip olmadığını bilmek, eşzamanlı Ruby yazmaları gerçekten performans göstermesi için önemlidir.
Eşzamanlılık yaygın bir ihtiyaç olduğundan ve GVL temel olarak doğru yaklaşımı şekillendirdiğinden, bunu anlamak — threadlerin neden CPU işini paralelleştirmediği, I/O için yardımcı olduğu ve CPU paralelizminin işlem gerektirdiği — sık karşılaşılan bir hatayı önleyen ve Ruby'nin eşzamanlılık modeli ile GVL kısıtlamasının anlaşılmasını yansıtan yaygın bir mülakat konusu olan senior-level önemli bilgidir.