An operating system is the gatekeeper for system resources. It decides which processes receive processing time, memory, and network access, making it possible for multiple jobs to coexist without every application directly controlling the hardware. section 2.0
For concurrent programming, the operating system supplies the basic model for running more than one task. Processes and threads act as concurrent actors: they can interleave their work, interact, and sometimes execute in parallel. Understanding this model helps explain where goroutines fit and why concurrent programs do not simply run in a fixed, sequential order. section 2.0 section 1.1
Multiprocessing, also called multiprogramming, lets an operating system handle more than one task at a time. Its practical purpose is to keep the CPU useful: when one job cannot proceed, such as while waiting for user input or file I/O, another ready job can run instead. section 2.1
A job commonly moves through a small set of scheduling states:
- It enters a job queue after submission when it is not yet ready to run. section 2.1
- It moves to the ready queue once it can run; Linux may call this the run queue. section 2.1
- It executes when the operating system selects it for an available CPU. section 2.1
- It waits in an I/O queue after requesting data from a device, allowing another ready job to use the CPU. section 2.1
Searching a large file
A command that searches a large file begins as a submitted job, becomes ready, and runs on the CPU. When it requests file data, it leaves the CPU for I/O waiting. The operating system can then schedule another ready job rather than leaving the processor idle. section 2.1
Use the job-state figure to trace how a single-CPU system alternates work between ready jobs and jobs waiting for I/O. section 2.1
