Das GVL (Global VM Lock, ehemals GIL) in MRI Ruby erlaubt nur einem Thread die gleichzeitige Ausführung von Ruby-Code — Threads bieten also keine echte CPU-Parallelität. Allerdings wird das GVL während I/O freigesetzt, sodass Threads tatsächlich bei I/O-gebundenen Arbeiten helfen. Für CPU-Parallelität verwendest du mehrere Prozesse. Dies spiegelt Pythons GIL-Situation wider.
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 helfen bei I/O-gebundenen Arbeiten (Netzwerk, Datei, DB), weil das GVL während des Wartens freigesetzt wird und andere Threads laufen können. Sie beschleunigen nicht CPU-gebundene Arbeiten (das GVL serialisiert die Ruby-Ausführung).
# ✅ 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
Für CPU-gebundene Parallelität verwendest du mehrere Prozesse (jeder mit seinem eigenen GVL/Interpreter) — fork, das parallel Gem oder mehrere Worker-Prozesse (wie Rails-Server wie Puma skaliert werden).
✓ 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
Das GVL und Ruby-Concurrency zu verstehen ist wichtig — und häufig missverstanden — Wissen für die Erstellung performanter Ruby-Anwendungen, ähnlich wie Pythons GIL-Situation.
Der Kerngedanke ist, dass MRI Rubys GVL nur einem Thread die gleichzeitige Ausführung von Ruby-Code erlaubt, sodass Threads keine CPU-Parallelität bieten — ein häufiger Verwirrungspunkt.
Kritisch ist, dass das GVL während I/O freigesetzt wird, was bedeutet, dass der richtige Concurrency-Ansatz von der Workload abhängt: Threads funktionieren gut für I/O-gebundene Aufgaben (Netzwerkaufrufe, Datei-/Datenbankzugriff — wo das GVL während Wartezeiten freigesetzt wird, was Threads ermöglicht zu überlappen), aber CPU-gebundene Parallelität erfordert mehrere Prozesse (jeder mit seinem eigenen GVL, erreichend echte Parallelität über Cores — über fork, das parallel Gem oder mehrere Worker-Prozesse, wie Rails-Server skaliert werden).
Missverstehen des GVL führt zu unwirksamen Concurrency-Code (z. B. Verwendung von Threads für CPU-intensive Arbeiten mit erwarteter Beschleunigung).
Das Wissen um die I/O-vs-CPU-Entscheidung (Threads für I/O-Concurrency, Prozesse für CPU-Parallelität), moderne Tools (Ractors für experimentelle echte Parallelität, Fibers/async für cooperative High-I/O-Concurrency, Background-Job-Prozessoren wie Sidekiq) und dass alternative Implementierungen (JRuby, TruffleRuby) das GVL nicht haben, ist wichtig um concurrent Ruby zu schreiben, das tatsächlich performant ist.
Da Concurrency ein häufiges Bedürfnis ist und das GVL den richtigen Ansatz grundlegend prägt, ist das Verständnis dafür — warum Threads CPU-Arbeiten nicht parallelisieren, dass sie bei I/O helfen und dass Prozesse für CPU-Parallelität notwendig sind — wichtiges Wissen auf Senior-Level, das einen häufigen Fehler verhindert und ist ein häufiges Interview-Thema, das das Verständnis von Rubys Concurrency-Modell und dessen GVL-Einschränkung widerspiegelt.