ما هو GVL وكيف يعمل التزامن (Concurrency) في Ruby؟

Question

Accepted Answer

**GVL** (Global VM Lock، المعروف سابقًا باسم GIL) في MRI Ruby يسمح بتنفيذ **خيط واحد فقط لكود Ruby في نفس الوقت** — لذا الخيوط لا توفر توازيًا حقيقيًا على المعالج. لكن GVL يتم **تحريره أثناء العمليات الإدخال/الإخراج**، لذا الخيوط *تساعد فعلًا* للعمل المرتبط بالإدخال/الإخراج. للتوازي على المعالج، تستخدم عمليات متعددة. هذا يعكس موقف GIL في Python.

## GVL: خيط واحد ينفذ كود 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.
```

## الخيوط — جيدة للتزامن المرتبط بالإدخال/الإخراج

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

الخيوط تساعد للعمل المرتبط بالإدخال/الإخراج (الشبكة، الملفات، قواعد البيانات) لأن GVL يتم تحريره أثناء الانتظار، مما يسمح لخيوط أخرى بالتنفيذ. إنها **لا تسرع** العمل المرتبط بالمعالج (GVL يسلسل تنفيذ Ruby).

## العمليات — للتوازي المرتبط بالمعالج

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

للتوازي المرتبط بالمعالج، استخدم **عمليات متعددة** (كل منها لديها GVL/مفسّر خاص بها) — `fork`، gem `parallel`، أو تشغيل عمليات عاملة متعددة (كيف تتسع خوادم 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 عالية الأداء، تمامًا كموقف GIL في Python.

البصيرة الرئيسية هي أن **GVL في MRI Ruby يسمح بتنفيذ خيط واحد فقط لكود Ruby في نفس الوقت**، لذا الخيوط **لا توفر** التوازي على المعالج — وهذه نقطة التباس شائعة.

بشكل حاسم، **GVL يتم تحريره أثناء العمليات الإدخال/الإخراج**، وهذا يعني أن نهج التزامن الصحيح يعتمد على حمل العمل: **الخيوط تعمل بشكل جيد للمهام المرتبطة بالإدخال/الإخراج** (استدعاءات الشبكة، الوصول للملفات/قواعد البيانات — حيث يتم تحرير GVL أثناء الانتظار، مما يسمح للخيوط بالتداخل)، لكن **التوازي المرتبط بالمعالج يتطلب عمليات متعددة** (كل منها لديها GVL خاص بها، تحقيق توازي حقيقي عبر الأنوية — عبر `fork`، gem `parallel`، أو عمليات عاملة متعددة، وهذا هو كيف تتسع خوادم Rails).

سوء فهم GVL يؤدي لكود تزامن غير فعال (على سبيل المثال استخدام الخيوط للعمل الثقيل على المعالج مع توقع تسريع).

معرفة قرار الإدخال/الإخراج مقابل المعالج (الخيوط للتزامن المرتبط بالإدخال/الإخراج، العمليات للتوازي المرتبط بالمعالج)، الأدوات الحديثة (Ractors للتوازي الحقيقي التجريبي، Fibers/async للتزامن التعاوني العالي للإدخال/الإخراج، معالجات الوظائف الخلفية مثل Sidekiq)، وأن التطبيقات البديلة (JRuby، TruffleRuby) تفتقد GVL مهم لكتابة Ruby متزامن يعمل بفعالية.

بما أن التزامن حاجة شائعة و GVL يشكل بشكل أساسي النهج الصحيح، فهمه — لماذا الخيوط لا تعطي توازيًا للعمل المرتبط بالمعالج، أنها تساعد للإدخال/الإخراج، وأن العمليات مطلوبة للتوازي المرتبط بالمعالج — هذا معرفة مهمة على مستوى أعلى تمنع خطأ شائع وهي موضوع مقابلة شائع يعكس فهم نموذج التزامن في Ruby وقيود GVL الخاص به.