რა არის GVL და როგორ მუშაობს კონკურენტობა Ruby-ში?

Question

Accepted Answer

**GVL** (Global VM Lock, ადრე GIL) MRI Ruby-ში საშუალებას აძლევს მხოლოდ **ერთ thread-ს გაუშვას Ruby კოდი ერთდროულად** — ამიტომ threads არ იძლევა true CPU parallelism. მაგრამ GVL **გათავისუფლდება I/O-ს დროს**, ამიტომ threads *სამართებულია* I/O-bound სამუშაოსთვის. CPU parallelism-ისთვის იყენებთ მრავალ processes. ეს Python-ის GIL სიტუაციის მსგავსია.

## GVL: ერთი thread ხელმისაწვდომელი Ruby კოდი ერთ დროს

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

## Threads — კარგი I/O-bound კონკურენტობისთვის

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

Threads სამართებელია I/O-bound სამუშაოსთვის (network, file, DB) იმიტომ, რომ GVL გათავისუფლდება wait-ის დროს, რაც საშუალებას იძლევა სხვა threads-ებმა გაითავლონ. ისინი **არ აჩქარებენ** CPU-bound სამუშაოს (GVL serializes Ruby execution-ს).

## Processes — CPU-bound parallelism-ისთვის

```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-bound parallelism-ისთვის გამოიყენეთ **მრავალი processes** (თითოეული საკუთარი GVL/interpreter-ით) — `fork`, `parallel` gem, ან რამდენიმე worker processes-ის გაშვება (როგორ ზრდება Rails სერვერები, როგორიცაა Puma).

## თანამედროვე კონკურენტობის ხელსაწყოები

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

## რატომ მნიშვნელოვანია ეს

GVL-ის და Ruby კონკურენტობის გაგება მნიშვნელოვანი — და ხშირად ღირსეშემეცნებული — ცოდნა მაღალპროდუქტიული Ruby აპლიკაციების აგებისთვის, ისევე როგორც Python-ის GIL სიტუაცია.

მთავარი insight არის ის, რომ MRI Ruby-ის **GVL საშუალებას აძლევს მხოლოდ ერთ thread-ს შეასრულოს Ruby კოდი ერთ დროს**, ამიტომ threads **არ იძლევა** CPU parallelism — ხშირი დაბნეულობის წერტილი.

კრიტიკულად, GVL **გათავისუფლდება I/O-ს დროს**, რაც ნიშნავს, რომ სწორი კონკურენტობის მიდგომა დამოკიდებულია workload-ზე: **threads კარგად მუშაობს I/O-bound ამოცანებისთვის** (network calls, file/database access — სადაც GVL გათავისუფლდება waits-ის დროს, რაც threads-ებს საშუალებას აძლევს გადაკვეთონ), მაგრამ **CPU-bound parallelism-ისთვის საჭიროა მრავალი processes** (თითოეული საკუთარი GVL-ით, ამოღწევს true parallelism cores-ებზე — `fork`-ის, `parallel` gem-ის, ან რამდენიმე worker processes-ის საშუალებით, რაც Rails სერვერების ზრდის წესია).

GVL-ის ღირსეშემეცნება იწვევს ინეფექტიან კონკურენტობის კოდს (მაგ. threads-ის გამოყენება CPU-heavy სამუშაოსთვის speedup-ის შემოსახლვით).

I/O-vs-CPU გადაწყვეტილების ცოდნა (threads I/O კონკურენტობისთვის, processes CPU parallelism-ისთვის), თანამედროვე ხელსაწყოები (Ractors ექსპერიმენტული true parallelism-ისთვის, Fibers/async მაღალი I/O cooperative კონკურენტობისთვის, background job processors როგორიცაა Sidekiq), და რომ ალტერნატიული implementations (JRuby, TruffleRuby) ნაკლებ GVL-ს აწვდიან მნიშვნელოვანია concurrent Ruby-ის დასაწერად, რომელიც აქტუალურად გამოსახელი არის.

ვინაიდან კონკურენტობა ხშირი საჭიროება და GVL ფუნდამენტურად ფორმირებს სწორი მიდგომას, მისი გაგება — რატომ არ უშვებს threads CPU სამუშაოს, რომ ისინი სამართებელია I/O-ისთვის, და რომ processes საჭიროა CPU parallelism-ისთვის — მნიშვნელოვანი senior-level ცოდნაა, რომელიც თავს ერიდება ხშირ შეცდომას და არის ჯავშანი ინტერვიუს თემა, რომელიც ასახავს Ruby-ის კონკურენტობის მოდელის გაგებას და მისი GVL შეზღუდვას.