Go runtime scheduler કેવી રીતે કાર્ય કરે છે?

Question

Accepted Answer

Go runtime એમાં **scheduler** શામેલ છે જે ઘણા goroutines ને OS threads ની નાની સંખ્યા પર ગુણાકાર કરે છે. આ **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 ના નાના 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 હોગ કરતા અટકાવે છે, અને નિર્ણાયક રીતે, જ્યારે 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 ડિઝાઇન દ્વારા થોડા OS threads પર ઘણા goroutines) સમજવું બતાવે છે *શા માટે* Go લક્ષ લાખો goroutines ચલાવી શકે છે જ્યારે OS threads હજારોમાં મર્યાદિત છે, અને *શા માટે* તેની concurrency એટલી કાર્યક્ષમ છે (મંહાઈ OS context switches ને બદલે user-space switching, GOMAXPROCS દ્વારા cores આર સાચી parallelism).

Blocking નું સ્માર્ટ હેન્ડલીંગ (channel-blocked goroutines ને પાર્ક કરવું, syscalls પર P હેન્ડ ઓફ કરવું કે threads બર્બાद ન થાય), **work stealing** load balancing માટે, અને **preemption** (1.14 માંથી) starvation અટકાવવા માટે એ છે જે Go ની concurrency વાસ્તવ workloads હેઠળ મજબૂત બનાવે છે.

જીણે તમે rarely scheduler સાથે સીધું વર્તો છો, તેને સમજવું goroutine performance માટે તમારું intuition ગહન કરે છે, behaviors (શા માટે blocking threads બર્બાદ કરતું નથી, શા માટે તમે ઘણા goroutines સ્પષ્ટ કરી શકો), અને નિર્ણયોને સૂચવે છે જેમ concurrency બાંધવું.

તે એક advanced topic છે જે Go runtime knowledge નું સત્ય depth દર્શાવે છે અને senior interviews માં મૂલ્યવાન છે.