Go runtime scheduler कैसे काम करता है?

Question

Accepted Answer

Go runtime में एक **scheduler** शामिल है जो कई goroutines को OS threads की एक छोटी संख्या पर multiplexes करता है। यह **M:N scheduling** (M goroutines N OS threads पर) वह है जो goroutines को इतना सस्ता बनाता है और Go की concurrency को इतनी scalable बनाता है। इसे समझना goroutine performance को समझाता है।

## The 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 करता है। डिफ़ॉल्ट रूप से (`GOMAXPROCS`) प्रति CPU core एक P है, प्रत्येक के साथ चलाने के लिए तैयार 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 user space में goroutine switching को संभालता है (kernel-level thread switches नहीं), और goroutines के पास tiny 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 को busy रखता है, **preemption** एक goroutine को core hogging से रोकता है, और महत्वपूर्ण रूप से, जब एक 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 free नहीं हैं, हालांकि

```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 के माध्यम से कुछ OS threads पर कई goroutines) को समझना समझाता है *क्यों* Go लाखों goroutines चला सकता है जब OS threads हजारों में maxed हो जाते हैं, और *क्यों* इसकी concurrency इतनी efficient है (costly OS context switches के बजाय user-space switching, GOMAXPROCS के माध्यम से cores में true parallelism)।

Blocking की smart handling (channel-blocked goroutines को parking करना, syscalls पर P को hand off करना ताकि threads बर्बाद न हों), load balancing के लिए **work stealing**, और starvation को रोकने के लिए **preemption** (1.14 के बाद से) वह हैं जो Go की concurrency को real workloads के तहत robust बनाते हैं।

हालांकि आप शायद ही कभी scheduler के साथ सीधे interact करते हैं, इसे समझना goroutine performance के लिए आपके intuition को गहरा करता है, behaviors को समझाता है (क्यों blocking threads को बर्बाद नहीं करता, क्यों आप कई goroutines spawn कर सकते हैं), और concurrency को bounding करने जैसे निर्णयों को inform करता है।

यह एक advanced topic है जो Go runtime knowledge की genuine depth को demonstrate करता है और senior interviews में मूल्यवान है।