How Programs Actually Run MOC

Above the level of your code and below the level of the machine sits the runtime: the scheduler, the memory model, the collector, the boundary to the kernel. Most of the surprising behavior of a program under load - a stall, a race, a pause, a syscall storm - lives here, in machinery you did not write and usually do not see. These notes map that layer: how work reaches a core, how threads share memory without corrupting it, and what every trip out of your process costs.

Scheduling: getting work onto a core

• Threads vs coroutines: who decides to yield - who decides when a task yields, and what each one costs.
• The Go scheduler: G, M, and P - the same M:N model worked out in full: G, M, and P.
• CPU-bound vs IO-bound - which kind of work you have, and therefore which model fits.

Async: overlapping the waiting

• Async/await: syntax over a state machine - the keyword is syntax over a state machine that pauses and resumes.
• The cost of async - what that convenience costs, and when plain synchronous code wins.

Memory: sharing it safely

• Memory models: the rules behind happens-before - happens-before, and why concurrent code needs a contract about order.
• Garbage collection: the pause you didn't schedule - handing the runtime the decision of when memory is safe to reclaim.

The kernel boundary

• System calls: the border crossing - the one controlled crossing out of your process, and the toll on each trip.

Where this map meets the performance one: scheduling, GC pauses, and syscall counts are three of the biggest reasons a system that looked fast in isolation slows down once real load arrives.