كيف يعمل جدولة وقت التشغيل (Scheduler) في Go؟

Question

Accepted Answer

وقت تشغيل Go يتضمن **جدولة** تقوم بتحويل عدد كبير من goroutines إلى عدد صغير من threads نظام التشغيل. هذا **جدولة M:N** (M goroutines على N OS threads) هو ما يجعل goroutines رخيصة جداً ويجعل التزامن في Go قابلاً للتوسع بشكل كبير. فهم آلية عملها يشرح أداء goroutines.

## نموذج G-M-P

```text
G (Goroutine) — your concurrent task (lightweight, ~2KB stack to start)
M (Machine)   — an OS thread (the actual thread the OS schedules)
P (Processor) — a logical processor / scheduling context; holds a queue of runnable Gs
                (the number of P's = GOMAXPROCS, default = number of CPU cores)

The scheduler runs G's on M's, coordinated through P's:
  Each P has a local run queue of goroutines; an M must hold a P to run G's.
```

وقت التشغيل يعيّن عدد كبير من goroutines (G) إلى threads نظام التشغيل (M) عبر معالجات منطقية (P). يوجد P واحد لكل نواة CPU بشكل افتراضي (`GOMAXPROCS`)، وكل منها يحتوي على قائمة انتظار من goroutines جاهزة للتشغيل.

## كيف تحقق التزامن رخيص وقابل للتوسع

```text
✓ Creating a goroutine is cheap (tiny stack, runtime-managed) → millions feasible
✓ Switching goroutines happens in USER space (runtime), not via expensive OS
  context switches → far lighter than switching OS threads
✓ With P = CPU cores, Go runs goroutines truly in parallel across cores
```

لأن جدولة Go تتعامل مع تبديل goroutines في مساحة المستخدم (وليس تبديل threads على مستوى kernel)، و goroutines لها أكوام صغيرة جداً، يمكنك تشغيل عدد أكبر بكثير من goroutines مقابل threads نظام التشغيل، وبرخص.

## سلوكيات جدولة رئيسية

```text
✓ Work stealing — an idle P STEALS goroutines from a busy P's queue → load balancing
✓ Cooperative + preemptive — goroutines yield at function calls/channel ops/blocking;
  since Go 1.14, the scheduler can also PREEMPT long-running goroutines (no starvation)
✓ Blocking handled smartly:
   - A goroutine blocked on a CHANNEL/sync → parked, the M runs other goroutines (no thread wasted)
   - A goroutine blocked on a SYSCALL (e.g. file I/O) → the M blocks, but the P is
     handed to ANOTHER M so other goroutines keep running
```

**سرقة العمل** تبقي cores مشغولة، **الإيقاف المؤقت** يمنع goroutine واحد من احتكار core، والأهم من ذلك، عندما يتم حظر goroutine (على قناة أو syscall)، تحافظ جدولة على تشغيل goroutines أخرى بدلاً من إهدار thread.

## GOMAXPROCS

```go
runtime.GOMAXPROCS(4)    // limit to 4 OS threads running Go code simultaneously
// default = number of CPU cores; rarely needs changing
```

## لماذا goroutines ليسوا مجانيين تماماً

```text
Goroutines are cheap but not zero-cost — millions still use memory, and excessive
goroutines add scheduling overhead. Bound concurrency (worker pools) for heavy loads.
```

## لماذا يهم

جدولة Go هي محرك رخص goroutines المذهل وقابليتهم للتوسع — فهم **نموذج M:N** (العديد من goroutines على عدد قليل من OS threads عبر تصميم G-M-P) يشرح *لماذا* يمكن لـ Go تشغيل ملايين goroutines عندما يصل OS threads إلى الآلاف، و*لماذا* تزامنه فعال جداً (تبديل في مساحة المستخدم بدلاً من عمليات تبديل السياق المكلفة على مستوى OS، التوازي الحقيقي عبر cores عبر GOMAXPROCS).

التعامل الذكي مع الحظر (وضع goroutines المحجوزة بواسطة القنوات، تسليم P على syscalls لذا لا يتم إهدار threads)، **سرقة العمل** لموازنة الحمل، و**الإيقاف المؤقت** (منذ 1.14) لمنع الجوع هي ما تجعل تزامن Go قوياً تحت أحمال العمل الحقيقية.

على الرغم من أنك نادراً ما تتفاعل مع جدولة مباشرة، فإن فهمها يعمق حدسك حول أداء goroutine، ويشرح السلوكيات (لماذا الحظر لا يهدر threads، لماذا يمكنك استنبات عدد كبير جداً من goroutines)، ويؤثر على القرارات مثل حد التزامن.

هذا موضوع متقدم يوضح معرفة حقيقية بعمق وقت تشغيل Go وهو مقدّر في المقابلات العليا.