Mitä on GVL ja miten samanaikaisuus toimii Rubyssa?

Question

Accepted Answer

**GVL** (Global VM Lock, entinen GIL) MRI Rubyssa sallii vain **yhden säikeen suorittaa Ruby-koodia kerrallaan** — joten säikeet eivät tarjoa todellista CPU-parallelismia. GVL kuitenkin **vapautuu I/O-operaatioiden aikana**, joten säikeet *auttavat* I/O-sidonnaisissa töissä. CPU-parallelismiin käytetään useita prosesseja. Tämä heijastaa Pythonin GIL-tilannetta.

## GVL: vain yksi säie suorittaa Ruby-koodia kerrallaan

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

## Säikeet — hyvät I/O-sidonnaiseen samanaikaisuuteen

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

Säikeet auttavat I/O-sidonnaisissa töissä (verkko, tiedosto, tietokanta), koska GVL vapautuu odotuksen aikana, mikä antaa muille säikeille mahdollisuuden toimia. Ne **eivät** nopeuta CPU-pohjaista työtä (GVL sarjoittaa Ruby-suorituksen).

## Prosessit — CPU-pohjaisen parallelismin kannalta

```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-pohjaisen parallelismin kannalta käytä **useita prosesseja** (joilla kullakin on oma GVL/tulkki) — `fork`, `parallel` gem tai useiden worker-prosessien ajaminen (kuinka Rails-palvelimet kuten Puma skaalautuvat).

## Moderni samanaikaisuustyökalut

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

## Miksi se on tärkeää

GVL:n ja Rubyn samanaikaisuuden ymmärtäminen on tärkeää — ja usein väärinymmärrettyä — tietoa suorituskykyisten Ruby-sovellusten rakentamiseen, samoin kuin Pythonin GIL-tilannetta.

Pääasiallinen näkemys on, että MRI Rubyn **GVL sallii vain yhden säikeen suorittaa Ruby-koodia kerrallaan**, joten säikeet eivät tarjoa CPU-parallelismia — tämä on yleinen väärinkäsitys.

Kriittisesti tärkeää on, että GVL **vapautuu I/O-operaatioiden aikana**, mikä tarkoittaa, että oikea samanaikaisuuslähestymistapa riippuu työkuormasta: **säikeet toimivat hyvin I/O-sidonnaisissa tehtävissä** (verkkokutsut, tiedosto/tietokannan käyttö — missä GVL vapautuu odotuksissa, antaen säikeille mahdollisuuden limittyä), mutta **CPU-pohjainen parallelismi vaatii useita prosesseja** (joilla kullakin on oma GVL, saavuttaen todellisen parallelismin ytimissä — `fork`in, `parallel` gemin tai useiden worker-prosessien kautta, joka on kuinka Rails-palvelimet skaalautuvat).

GVL:n väärinymmärtäminen johtaa tehottomaan samanaikaisuuskoodiin (esim. säikeillä CPU-raskaita töitä odottamalla nopeutta).

I/O-vs-CPU päätöksen tunteminen (säikeet I/O-samanaikaisuuteen, prosessit CPU-parallelismiin), moderni työkalut (Ractor kokeellisen todellisen parallelismin kannalta, Fiber/async korkean I/O-yhteistyön samanaikaisuuteen, taustatyöprosessorit kuten Sidekiq) ja että vaihtoehtoiset toteutukset (JRuby, TruffleRuby) vailla GVL:ää on tärkeää samanaikaiseen Rubyyn, joka todella toimii.

Koska samanaikaisuus on yleinen tarve ja GVL muokkaa perusteellisesti oikean lähestymistavan, sen ymmärtäminen — miksi säikeet eivät parallelisoi CPU-työtä, että ne auttavat I/O:ssa, ja että prosesseja tarvitaan CPU-parallelismiin — on tärkeää senior-tason tietämystä, joka estää yleisen virheen ja on yleinen haastattelun aihe, joka heijastaa Rubyn samanaikaisuusmallin ja sen GVL-rajoitteen ymmärtämistä.