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) लाई logical processors (P) को माध्यमबाट OS threads (M) मा map गर्छ। Default मा प्रत्येक CPU core को लागि एक P छ (`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 लाई busy राख्छ, **preemption** ले एक goroutine लाई core लाई होग गर्नबाट रोक्छ, र मुख्य रूपमा, जब एक 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 को पछाड़ि को engine हो — यसको **M:N model** (G-M-P design को माध्यमबाट धेरै goroutines केही OS threads मा) को बुझ्नुले *किन* Go लाई मिलियनन् goroutines चलाउन सक्छ जब OS threads हजारमा अधिकतम हुन्छ भनेर व्याख्या गर्छ, र *किन* यसको concurrency यति प्रभावकारी छ (user-space switching को कारण महँगो OS context switches को सट्टामा, GOMAXPROCS को माध्यमबाट cores मा साँचो parallelism)।

Blocking को स्मार्ट हेरचाह (channel-blocked goroutines को parking, syscalls मा P लाई हस्तांतरण गरी threads नष्ट नहोस्), **work stealing** load balancing को लागि, र **preemption** (1.14 देखि) starvation रोक्न को लागि यो हो जसले Go को concurrency को वास्तविक workloads अन्तर्गत robust गर्छ।

यद्यपि तपाई विरलै scheduler सँग सीधै अन्तरक्रिया गर्नुहुन्छ, यसलाई बुझ्नुले goroutine performance को लागि आपनो intuition गहिराइ गर्छ, behaviors लाई व्याख्या गर्छ (किन blocking ले threads नष्ट गर्दैन, किन तपाई यति धेरै goroutines spawn गर्न सक्नुहुन्छ), र decisions लाई सूचित गर्छ जस्तै concurrency लाई बाध्य पारी।

यो एक उन्नत विषय हो जसले Go runtime knowledge को साँचो गहिराइ प्रदर्शन गर्छ र senior interviews मा मूल्यवान छ।