Operating Systems

An operating system's entire job is to take the single CPU, single pool of DRAM, and single disk described in the previous topic and share them safely across every program running at once, without those programs ever having to coordinate with each other directly. A process is one running program — the terminal shell from the working-with-a-computer topic launches a new process every time a command runs — and the OS gives each process its own private memory, including its own stack and heap from the memory-and-execution topic, so one process can never accidentally read or overwrite another's data. A thread is a lighter-weight unit of execution living inside a process: multiple threads in the same process share that process's memory directly, which makes communicating between them cheap but also means a bug in one thread can corrupt data another thread depends on, a tradeoff processes avoid entirely by staying isolated. Scheduling is how the OS decides which process or thread actually gets the CPU at any given instant, since there are usually far more of them than there are CPU cores: the scheduler rapidly switches between them, giving each a small time slice, which is what makes dozens of programs look like they are all running simultaneously on hardware that is really only executing one instruction stream per core at a time. Virtual memory extends that same illusion to memory itself: every process is given what looks like its own complete, private address space starting at address zero, while the OS's memory manager silently translates those virtual addresses into real physical DRAM locations behind the scenes using a structure called a page table — and when physical DRAM runs short, the OS can even swap a rarely used page out to disk, trading the memory hierarchy's slowest tier for extra breathing room. A filesystem organizes the disk itself into the files and directories this series already introduced, keeping track of which physical disk blocks belong to which file so that path lookups and reads resolve correctly. None of this — process isolation, scheduling, virtual memory, filesystem access — is something a regular program is allowed to do directly; instead it makes a system call, a tightly controlled request that hands control briefly to the OS kernel, which performs the privileged operation on the program's behalf and hands control back, the exact gateway every `ls`, `read()`, or `malloc()` ultimately passes through. This whole layer of isolation and resource-sharing is what the next topic, computer networks, will extend outward from one machine to many, using many of these same ideas — addressing, controlled access, and shared resources — at a much larger scale.