Go ਰਨਟਾਈਮ ਸ਼ਡਿਊਲਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

Question

Accepted Answer

Go ਰਨਟਾਈਮ ਵਿੱਚ ਇੱਕ **scheduler** ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੇ goroutines ਨੂੰ OS threads ਦੀ ਇੱਕ ਛੋਟੀ ਸੰਖਿਆ ਤੇ ਮਲਟੀਪਲੈਕਸ ਕਰਦਾ ਹੈ। ਇਹ **M:N scheduling** (M goroutines ਨੂੰ N OS threads ਤੇ) ਹੀ ਹੈ ਜੋ goroutines ਨੂੰ ਇੰਨਾ ਸਸਤਾ ਅਤੇ Go ਦੇ concurrency ਨੂੰ ਇੰਨਾ scalable ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਸਮਝਣਾ goroutine performance ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ।

## 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) ਨੂੰ OS threads (M) ਦੇ ਨਾਲ logical processors (P) ਦੁਆਰਾ ਮੈਪ ਕਰਦਾ ਹੈ। ਡਿਫਾਲਟ ਤੌਰ ਤੇ ਪ੍ਰਤੀ CPU core ਇੱਕ P ਹੁੰਦਾ ਹੈ (`GOMAXPROCS`), ਹਰ ਇੱਕ ਕੋਲ ਚਲਾਉਣ ਲਈ ਤਿਆਰ goroutines ਦੀ ਇੱਕ ਕਤਾਰ ਹੁੰਦੀ ਹੈ।

## ਇਹ ਸਸਤੇ, 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 ਸਵਿਚਿੰਗ ਨੂੰ user space ਵਿੱਚ ਸੰਭਾਲਦਾ ਹੈ (kernel-level thread switches ਨਹੀਂ), ਅਤੇ goroutines ਦੇ ਛੋਟੇ stacks ਹਨ, ਤੁਸੀਂ OS threads ਨਾਲੋ ਜ਼ਿਆਦਾ goroutines ਚਲਾ ਸਕਦੇ ਹੋ, ਸਸਤੇ ਵਿੱਚ।

## ਮੁੱਖ scheduler ਵਿਵਹਾਰ

```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 ਉੱਤੇ hog ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਤੌਰ ਤੇ, ਜਦੋਂ ਇੱਕ 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 ਮਾਡਲ** (G-M-P ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ ਕੁਝ OS threads ਤੇ ਬਹੁਤ ਸਾਰੇ goroutines) ਨੂੰ ਸਮਝਣਾ *ਕਿਉਂ* Go ਲੱਖਾਂ goroutines ਚਲਾ ਸਕਦਾ ਹੈ ਜਦੋਂ OS threads ਹਜ਼ਾਰਾਂ ਵਿੱਚ ਬਾਹਰ ਆ ਜਾਂਦੇ ਹਨ, ਅਤੇ *ਕਿਉਂ* ਇਸ ਦੀ concurrency ਇਤਨੀ efficient ਹੈ (user-space ਸਵਿਚਿੰਗ ਮਹਿੰਗੇ OS context switches ਦੀ ਥਾਂ, GOMAXPROCS ਦੁਆਰਾ cores ਵਾਰ ਅਸਲੀ parallelism) ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ।

Blocking ਦੀ ਮਾਸਲ ਹ੍ਰੇਤਾ (channel-blocked goroutines ਨੂੰ park ਕਰਨਾ, syscalls ਤੇ P ਨੂੰ ਹੱਥ ਲਗਾਉਣਾ ਤਾਂ threads ਬਰਬਾਦ ਨਾ ਹੋਣ), **work stealing** load balancing ਲਈ, ਅਤੇ **preemption** (1.14 ਤੋਂ) starvation ਤੋਂ ਬਚਾਉਣ ਲਈ ਇਹ ਖੁਦ ਨੂੰ Go ਦੀ concurrency ਨੂੰ ਅਸਲ ਦੇ workloads ਦੇ ਤਹਿਤ robust ਬਣਾਉਂਦਾ ਹੈ।

ਹਾਲਾਂਕਿ ਤੁਸੀਂ ਸ਼ਾਇਦ ਹੀ scheduler ਦੇ ਸਾਥ directly interact ਕਰਦੇ ਹੋ, ਇਸ ਨੂੰ ਸਮਝਣਾ goroutine performance ਲਈ ਤੁਹਾਡੀ intuition ਨੂੰ ਡੂੰਘਾ ਕਰਦਾ ਹੈ, ਵਿਵਹਾਰ ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ (ਕਿਉਂ blocking threads ਨੂੰ ਬਰਬਾਦ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ goroutines spawn ਕਰ ਸਕਦੇ ਹੋ), ਅਤੇ concurrency ਨੂੰ ਬਾਂਧਣ ਵਾਂਗ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ।

ਇਹ ਇੱਕ advanced topic ਹੈ ਜੋ Go runtime knowledge ਦੀ ਅਸਲ ਡੂੰਘਾਈ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ senior interviews ਵਿੱਚ ਕਦਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।