Go runtime scheduler کیسے کام کرتا ہے؟

Question

Accepted Answer

Go runtime میں ایک **scheduler** شامل ہے جو بہت سے goroutines کو OS threads کی ایک چھوٹی تعداد پر multiplex کرتا ہے۔ یہ **M:N scheduling** (M goroutines N OS threads پر) وہی ہے جو goroutines کو بہت سستا بناتا ہے اور Go کی concurrency کو scalable بناتا ہے۔ اس کو سمجھنا goroutine performance کی وضاحت کرتا ہے۔

## G-M-P model

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

Runtime بہت سے goroutines (G) کو OS threads (M) پر logical processors (P) کے ذریعے map کرتا ہے۔ ہر CPU core کے لیے ایک P ہے default کے طور پر (`GOMAXPROCS`)، ہر ایک کے پاس چلانے کے لیے تیار goroutines کی queue ہے۔

## یہ سستی، scalable concurrency کو کیسے حاصل کرتا ہے

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

کیونکہ scheduler goroutine switching کو user space میں سنبھالتا ہے (kernel-level thread switches نہیں)، اور goroutines کے پاس چھوٹے stacks ہیں، آپ OS threads کے مقابلے میں بہت زیادہ goroutines چلا سکتے ہیں، سستے میں۔

## Key scheduler behaviors

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

**Work stealing** cores کو مصروف رکھتا ہے، **preemption** ایک goroutine کو ایک core پر monopolize کرنے سے روکتا ہے، اور اہم بات یہ ہے کہ جب ایک goroutine block ہوتا ہے (channel یا syscall پر)، scheduler دوسرے 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 scheduler goroutines کی قابل ذکر سستی اور scalability کے پیچھے کا انجن ہے — اس کے **M:N model** کو سمجھنا (G-M-P design کے ذریعے بہت سے goroutines کم OS threads پر) وضاحت دیتا ہے *کیوں* Go لاکھوں goroutines چلا سکتا ہے جب OS threads ہزاروں میں زیادہ سے زیادہ ہوں، اور *کیوں* اس کی concurrency بہت موثر ہے (user-space switching بجائے مہنگے OS context switches کے، GOMAXPROCS کے ذریعے cores پر true parallelism)۔

Blocking کو سمارٹ طریقے سے ہینڈل کرنا (channel-blocked goroutines کو park کرنا، syscalls پر P کو hand off کرنا تاکہ threads ضائع نہ ہوں)، load balancing کے لیے **work stealing**، اور **preemption** (1.14 سے) starvation سے روکنے کے لیے وہی ہیں جو Go کی concurrency کو حقیقی workloads میں مضبوط بناتے ہیں۔

اگرچہ آپ scheduler کے ساتھ براہ راست کم ہی interact کرتے ہیں، اس کو سمجھنا goroutine performance کے لیے آپ کی intuition کو گہرا کرتا ہے، behaviors کی وضاحت کرتا ہے (کیوں blocking threads کو ضائع نہیں کرتا، کیوں آپ بہت سے goroutines spawn کر سکتے ہیں)، اور concurrency کو bound کرنے جیسے فیصلے میں معلومات فراہم کرتا ہے۔

یہ ایک advanced topic ہے جو Go runtime knowledge کی حقیقی گہرائی کو ظاہر کرتا ہے اور senior interviews میں قدر کیا جاتا ہے۔