Kaj je GVL in kako deluje sočasnost v Rubyju?

Question

Accepted Answer

**GVL** (Global VM Lock, prej GIL) v MRI Rubyju omogoča samo **enemu niti izvajati Ruby kodo naenkrat** — zato niti ne zagotavljajo prave CPU paralelnosti. Vendar je GVL **izpuščen med I/O**, zato niti *dejansko* pomagajo pri I/O-vezanem delu. Za CPU paralelnost uporabite več procesov. To je podobno situaciji s Pythonovim GIL.

## GVL: ena nit izvaja Ruby kodo naenkrat

```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.
```

## Niti — dobre za I/O-vezano sočasnost

```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
```

Niti pomagajo pri I/O-vezanem delu (mreža, datoteka, baza podatkov), ker je GVL izpuščen med čakanjem, kar drugim nitim omogoči, da se izvajajo. Njih **ne** pospešijo CPU-vezanega dela (GVL serializira Ruby izvajanje).

## Procesi — za CPU-vezano paralelnost

```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
```

Za CPU-vezano paralelnost uporabite **več procesov** (vsak s svojo GVL/interpreterjem) — `fork`, gem `parallel` ali več delavskih procesov (kako se strežniki Rails kot Puma razširjajo).

## Sodobna orodja za sočasnost

```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
```

## Zakaj je to pomembno

Razumevanje GVL in Ruby sočasnosti je pomembno — in pogosto napačno razumljeno — znanje za gradnjo zmogljivih Ruby aplikacij, podobno kot Pythonjeva situacija z GIL.

Ključni vpogled je, da MRI Rubyjev **GVL omogoča samo enemu niti izvajati Ruby kodo naenkrat**, zato niti *ne* zagotavljajo CPU paralelnosti — to je pogosta točka zmede.

Kritično je, da je GVL **izpuščen med I/O**, kar pomeni, da je pravi pristop sočasnosti odvisen od delovne obremenitve: **niti delujejo dobro za I/O-vezane naloge** (mrežni klici, dostop do datotek/baze podatkov — kjer je GVL izpuščen med čakanjem, kar nitim omogoči, da se prekrivajo), vendar **CPU-vezana paralelnost zahteva več procesov** (vsak s svojo GVL, dosega pravo paralelnost na jedrih — prek `fork`, gema `parallel` ali več delavskih procesov, kar je način, kako se strežniki Rails razširjajo).

Nepravilno razumevanje GVL vodi do neučinkovite kode sočasnosti (npr. uporaba niti za CPU-težko delo v pričakovanju pospeška).

Znanje odločitve I/O-vs-CPU (niti za I/O sočasnost, procesi za CPU paralelnost), sodobnih orodij (Ractors za eksperimentalno pravo paralelnost, Fibers/async za sočasnost z visokim I/O, procesorji za ozadijske naloge kot je Sidekiq) in da alternativne implementacije (JRuby, TruffleRuby) nimajo GVL je pomembno za pisanje sočasnega Rubyja, ki dejansko deluje.

Ker je sočasnost pogosta potreba in GVL temeljito oblikuje pravi pristop, razumevanje — zakaj niti ne paralelizirajo CPU dela, da pomagajo pri I/O in da so procesi potrebni za CPU paralelnost — je pomembno znanje na višji ravni, ki preprečuje pogosto napako in je pogost intervjuski predmet, ki odraža razumevanje Ruby modela sočasnosti in njegove omejitve GVL.