Yaya Go runtime scheduler ke aiki?

Question

Accepted Answer

Go runtime ya haɗa **scheduler** wanda ke ɗauka goroutines da yawa akan ƙarami adadi na OS threads. Wannan **M:N scheduling** (M goroutines akan N OS threads) shine abin da ya sa goroutines suke arha kuma Go's concurrency ya ƙarva. Fahimta shi za a bayyana 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 yana ɗaukar goroutines da yawa (G) akan OS threads (M) ta hanyar logical processors (P). Akwai P daya a kowane CPU core ta default (`GOMAXPROCS`), kowannensu yana da jerin goroutines da suke shirya.

## Yaya ya sami kula kyau, 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
```

Domin scheduler ke jiyawa da goroutine switching a sararin mai amfani (ba kernel-level thread switches ba), kuma goroutines suna da ƙananan stacks, za ka iya gudane goroutines da yawa fiye da OS threads, kyau.

## 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** ke ajiye cores masu aiki, **preemption** ke dakatar da goroutine daya daga kawar core, kuma mahimman, lokacin da goroutine ke toshe (akan channel ko syscall), scheduler ke ciyar da sauran goroutines a maimakon toshe thread.

## GOMAXPROCS

```go
runtime.GOMAXPROCS(4)    // limit to 4 OS threads running Go code simultaneously
// default = number of CPU cores; rarely needs changing
```

## Dalilin da goroutines ba free ba, duk da haka

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

## Dalilin da haka ya matuwa

Go scheduler shine injin a bayan goroutines ɓata kyau da scalability — fahimta shi **M:N model** (goroutines da yawa akan OS threads kadan ta hanyar G-M-P design) ya bayyana *dalilin da* Go ya iya gudane goroutines miliyoyin idan OS threads ke tsayawa a dubuwan, kuma *dalilin da* concurrency nsa ya zama mai kisifi (user-space switching a maimakon costly OS context switches, ainihin parallelism fiye da cores ta GOMAXPROCS).

Hada gwaninta a kan toshe (parking channel-blocked goroutines, handing P akan syscalls don kada threads ba su shake), **work stealing** don daidaita jiya, kuma **preemption** (tun 1.14) don dakatar da yunwa shine abin da ya sa Go's concurrency ya zama karfi a ƙarƙashin aiki na duniya.

Yadda aka kara haka kuma maka sauran scheduler kai tsaye, fahimta shi za ta zura duniya kan goroutine performance, za ta bayyana hali (dalilin da toshe ba ya shake threads, dalilin da ka iya budewa goroutines da yawa), kuma za ta ba da shawarwari kamar ɗauka concurrency.

Ita topic mai tsavakwa ce wanda ya nuna tunani na Go runtime kudi kuma ana yajiya a tsohon jita-jita.