Introduction to Operating Systems

A modern computer runs dozens of programs at once on a handful of CPU cores, a few gigabytes of memory, and one disk. None of those programs were written to cooperate with the others, yet they all run without stepping on each other. The operating system is what makes that possible — it is the referee sitting between every program and the hardware.

Because so much rides on the OS, understanding it stops being optional the moment your software gets serious. When a service is slow, a server runs out of memory, a process hangs, or two threads corrupt each other’s data, the engineers who understand the OS can actually reason about it — instead of guessing and restarting things until the symptom disappears.

• ▸Every syscall, thread, and memory allocation in your code is a request to the OS.
• ▸Performance problems (high CPU, thrashing, slow I/O, lock contention) are OS problems in disguise.
• ▸The goal of this series: replace "it just works" with "I know exactly what the OS is doing".

There are two ways to describe an OS, and both are true at once. Top-down, it is an abstraction layer: it hides messy hardware behind clean, uniform ideas like "files", "processes", and "memory" so you never have to talk to a specific disk controller or memory chip. Bottom-up, it is a resource manager: it decides which program gets the CPU right now, how much memory each one may use, and whose turn it is to touch the disk.

Abstraction (top-down)

Turns raw hardware into clean, portable concepts — files instead of disk sectors, processes instead of raw CPU time.

Resource manager (bottom-up)

Shares the CPU, memory, and devices fairly and safely among many programs that do not know about each other.

Kernel

The core of the OS that runs with full hardware privilege and enforces all of the above.

The single most important idea in the whole course is the boundary between user space and kernel space. Your program runs in user space, where it cannot touch hardware directly. When it needs something privileged — read a file, send a packet, get more memory — it makes a system call, which safely crosses into kernel space, does the privileged work, and returns.

This boundary is enforced by the CPU itself, which runs in either a restricted user mode or a fully-privileged kernel mode. It is why one buggy program cannot crash the whole machine or read another program’s memory — a protection we will keep coming back to.

User space

Where your applications run, with restricted privileges and no direct hardware access.

Kernel space

Where the OS core runs, with full control of the CPU, memory, and devices.

System call

The controlled doorway a program uses to ask the kernel to do privileged work on its behalf.

A running program is a process — the OS gives each one its own private view of memory and a record of its state. Inside a process, threads are the individual streams of execution that actually run on the CPU. Because there are far more processes and threads than CPU cores, the OS must constantly decide who runs next.

That decision is scheduling, and it is done thousands of times a second. A good scheduler creates the illusion that everything runs at once, keeps interactive apps snappy, and still gets long jobs done — a balancing act we will study in detail.

Process

A running program with its own memory space and OS bookkeeping.

Thread

A single line of execution inside a process; one process can have many.

Scheduler

The part of the OS that picks which thread runs on each CPU, and for how long.

The moment two threads share data, a new class of bug appears: race conditions, where the result depends on the exact timing of who runs first. To prevent them we use synchronization tools — locks, semaphores, condition variables — that let only one thread into a critical section at a time.

But synchronization brings its own danger. If two threads each hold a resource the other needs and neither will let go, they wait forever — a deadlock. Learning to prevent, avoid, detect, and recover from deadlock is a core OS skill that shows up directly in databases and multithreaded servers.

Race condition

A bug where the outcome depends on the unpredictable timing of concurrent threads.

Mutex / semaphore

Synchronization primitives that guard shared data so only permitted threads enter at once.

Deadlock

A standstill where threads each wait on resources the others hold — forever.

Every process believes it has a huge, private, contiguous block of memory starting at address zero. That is a carefully maintained illusion called virtual memory. In reality the OS and a hardware unit called the MMU translate those virtual addresses to scattered physical frames of RAM — and quietly page rarely-used data out to disk when RAM runs short.

This is how a machine with 8 GB of RAM can run programs that together ask for far more, and how one process is prevented from reading another’s memory. When the illusion breaks down — too little RAM, too much paging — you get thrashing, and performance falls off a cliff.

Virtual address space

The private, contiguous memory each process thinks it has.

Paging & the MMU

The mechanism that maps virtual pages to physical frames, on demand.

Page replacement

Deciding which page to evict to disk when memory is full.

Data has to outlive the power switch, so the OS provides the file system: the abstraction of named files in a tree of directories, sitting on top of a disk that really only understands numbered blocks. Underneath, structures like inodes and allocation tables track which blocks belong to which file.

Getting data to and from devices is the job of the I/O subsystem — controllers, interrupts, DMA, and device drivers — layered so that a single read() call works the same whether the data lives on a spinning disk, an SSD, or a network share.

File & directory

The named, tree-structured abstraction over raw disk blocks.

Inode

The on-disk record holding a file’s metadata and pointers to its data blocks.

I/O subsystem

Drivers, interrupts, and DMA that move data between programs and devices.

Zooming out, every topic in this course stacks into one picture: your programs on top, the kernel in the middle managing the CPU, memory, and devices, and the hardware at the bottom. Each part of the series fills in one layer of that picture.

Foundations

What an OS is, the hardware, system calls, and how a program becomes a process.

Processes & Scheduling

The process model, threads, context switching, schedulers, and IPC.

Concurrency & Memory

Synchronization, deadlock, address spaces, paging, and virtual memory.

Storage, Modern & Case Studies

File systems, virtualization, containers, Linux/Windows internals, and OS for databases.

By the end you will be able to reason about processes and threads, explain how virtual memory and file systems work, debug real performance problems, and see the operating-system ideas hiding inside the databases and servers you build every day.