Computer & OS Fundamentals · beginner · ~10 min
**What you will learn** - Name the main storage tiers (registers, cache, RAM, disk) and rank them by speed and persistence. - Explain the difference between *volatile* and *persistent* storage, and predict what survives a power-off. - Define a **process** precisely: code, virtual memory, open handles, environment, and a security context (the user it runs as). - Describe what a **thread** is, why threads are fast, and why shared memory causes **race conditions**. - Read a process listing and identify which user a process runs as. - Connect these ideas to the previous lesson, *How a computer runs a program*, and to the next one, *What an operating system does*.
Every program you run lives somewhere and uses something to do its work. "Somewhere" is memory and storage; "something" is the CPU. This lesson explains the four pieces that decide how fast and how safely software runs: the CPU, RAM, the disk, and the process abstraction the operating system builds on top of them.
In the prerequisite lesson, How a computer runs a program, you saw that source code becomes machine instructions that the CPU executes one after another. This lesson zooms out: where do those instructions and their data actually sit while the program runs, and how does the operating system package a running program so it cannot trample on its neighbours? The answer is a layered system. Data lives in a memory hierarchy — a few tiny ultra-fast registers inside the CPU, small caches close to it, a larger pool of RAM, and a big, slow, persistent disk. The operating system then wraps each running program in a process: a private address space plus the bookkeeping (open files, environment, identity) needed to keep it isolated from everything else.
This matters everywhere. It explains why a laptop feels slow when RAM fills up, why pulling the plug loses unsaved work but not your files, why a server can run hundreds of programs without them reading each other's data, and — in security — why "which user does this run as?" is one of the first questions an analyst asks. Once you have the vocabulary here, the next lesson, What an operating system does, will show how the OS schedules these processes onto the CPU and manages the memory underneath them.
These four concepts are the foundation under almost every performance, reliability, and security decision in software.
Performance. The gap between a CPU register and a disk read is roughly the difference between reaching into your pocket and driving to another city. Knowing which tier your data is in tells you why one program is instant and another stalls. When RAM fills up, the OS swaps memory to disk, and everything crawls — this is the single most common cause of a machine that "suddenly got slow."
Reliability. RAM is volatile: a crash or power cut erases everything not yet written to disk. That single fact drives auto-save, write-ahead logs in databases, and the habit of flushing important data to persistent storage.
Security. Process isolation is what stops one program from reading another's memory. The user a process runs as defines what it is allowed to do. Analysts use this constantly:
You cannot reason about any of these without first understanding what a process is and where data lives.
Definition. The memory hierarchy is the ordered set of places a computer stores data, arranged from smallest-and-fastest to largest-and-slowest: CPU registers → CPU cache (L1/L2/L3) → RAM → disk.
Plain explanation. Fast memory is expensive and tiny; cheap memory is huge but slow. Instead of choosing one, computers use all of them and constantly move "hot" data toward the fast tiers. The CPU only ever computes on data in registers, so data must be pulled up the hierarchy to be used.
How it works internally. When the CPU needs a value, it checks the nearest cache first. A cache hit returns it in a few cycles. A cache miss forces a slower trip to RAM (or, worse, disk), and the result is copied into cache so the next access is fast. This is why looping over data that fits in cache is dramatically faster than jumping around large structures.
Rough speed scale (orders of magnitude, not exact):
Tier Typical access time Persistent? Size
-------- -------------------- ----------- --------
Register < 1 nanosecond no bytes
L1 cache ~1 nanosecond no tens of KB
RAM ~50-100 nanoseconds no GBs
SSD disk ~50,000-100,000 ns YES hundreds of GB - TBs
HDD disk ~5,000,000+ ns YES TBs
When it matters / when not. You care about the hierarchy when performance matters (tight loops, large data, servers). For a one-off script that runs in a second, you can ignore it.
Common pitfall. Assuming all memory access costs the same. A program can be "doing the same number of operations" yet run 10x slower purely because of cache misses.
Knowledge check (explain in your own words): Why does a computer use four tiers instead of just one big fast memory?
Definition. Volatile storage loses its contents when power is removed (registers, cache, RAM). Persistent (non-volatile) storage keeps its contents across power-off and reboot (SSD, HDD, USB drives).
Plain explanation. RAM is a whiteboard wiped clean every time the lights go out. Disk is a filing cabinet that keeps its papers. Running programs and their working data live on the whiteboard; saved files live in the cabinet.
How it works internally. RAM stores bits as electrical charge that must be continuously refreshed; cut the power and the charge dissipates. Disks store bits as durable physical states (flash cells in an SSD, magnetic regions on an HDD) that persist without power.
When it matters / when not. Any time data must survive a crash or restart, it must reach persistent storage — and reach it fully (flushed, not just queued). For purely temporary scratch data, volatile RAM is perfect and faster.
Common pitfall. Believing "I clicked save, so it's safe." Writes can sit in a buffer in RAM before being flushed to disk; a power cut in that window loses them. This is exactly why databases use write-ahead logs.
Power ON Power OFF / crash
-------- -----------------
Registers [data] ----X----> gone
Cache [data] ----X----> gone
RAM [data] ----X----> gone
Disk [data] ====kept===> still there
Knowledge check (predict the outcome): You edit a document and the program shows your changes, but you have not saved. The power dies. Which tier held your changes, and are they recoverable?
Definition. A process is a running program plus all the state the operating system tracks for it: its code, its private virtual memory (stack, heap, and the program's own instructions), open file handles, its environment variables, and a security context — the user account it runs as.
Plain explanation. A program on disk is just a file, like a recipe in a book. A process is that recipe being cooked — with its own counter space, ingredients laid out, and a cook (the user) who is allowed to do certain things. The same program can be running as several independent processes at once.
How it works internally. The OS gives each process the illusion that it owns the whole machine through virtual memory: each process sees its own private address space starting at address 0, and the OS+hardware translate those virtual addresses to real physical RAM behind the scenes. Two processes can both use "address 0x1000" and never collide, because each maps to different physical memory. This translation is what enforces process isolation — one process cannot read another's memory by default.
Structure of a process's memory:
high addresses
+------------------+
| stack | function calls, local variables (grows down)
| | |
| v |
| |
| ^ |
| | |
| heap | dynamically allocated memory (grows up)
+------------------+
| data / globals | global and static variables
+------------------+
| code | the program's machine instructions (read-only)
+------------------+
low addresses
When it matters / when not. You think in processes whenever isolation, identity, or resource ownership matters: running a server, debugging, or analyzing what's on a machine. For pure algorithm logic inside one program, the process boundary is mostly invisible.
Common pitfall. Confusing a program (the file on disk) with a process (a running instance). Running the same browser twice creates two processes from one program.
Knowledge check (concept): Two processes both refer to memory address 0x4000. Why does neither see the other's data?
Definition. A thread is an independent execution path inside a process. A process always has at least one thread; it can have many. All threads in a process share that process's memory (heap, globals) but each has its own stack and CPU register state.
Plain explanation. If a process is a kitchen, threads are cooks working in it at the same time. They share the same counters and ingredients (memory), which lets them cooperate quickly — but if two reach for the same bowl at the same moment, they collide.
How it works internally. The OS scheduler can pause a thread between any two instructions and run another. Because threads share memory, two threads can read-modify-write the same variable in an interleaved order the programmer never intended. That is a race condition: the result depends on the unpredictable timing of which thread runs when.
Thread A: read counter (=5) ---------------> write 6
Thread B: read counter (=5) -> write 6
Result: counter == 6, but two increments happened -> should be 7. Lost update.
When to use / when not. Use threads to do work in parallel or to stay responsive while waiting (e.g., handling many clients). Avoid casual shared mutable state; when threads must share data, protect it (locks, atomics) or avoid sharing entirely. Don't add threads to a simple, fast, single-task script — they add complexity and bug surface for no gain.
Common pitfall. Assuming counter = counter + 1 is a single, indivisible step. It is read, add, write — three steps another thread can interrupt.
Knowledge check (find-the-bug): Two threads each run
total += amount;1000 times on a sharedtotal. Why might the final value be less than 2000 timesamount?
+-------------------------------------------------------+
| CPU |
| registers + L1/L2/L3 cache (fastest, volatile) |
+---------------------------|---------------------------+
| reads/writes
+---------------------------v---------------------------+
| RAM (volatile) |
| +-----------+ +-----------+ +-----------+ |
| | Process A | | Process B | | Process C | |
| | thr1 thr2 | | thr1 | | thr1 thr2 | |
| | (private | | (private | | (private | |
| | vmem) | | vmem) | | vmem) | |
| +-----------+ +-----------+ +-----------+ |
+---------------------------|---------------------------+
| load / save / swap
+---------------------------v---------------------------+
| Disk (slow, PERSISTENT) |
| program files, saved data, swap space |
+-------------------------------------------------------+
This is a concept lesson, so there is no programming syntax to memorize. Instead, learn the small set of commands that let you observe these ideas on a real machine. On Linux/macOS:
free -h # show RAM used vs free (Linux); on macOS use: vm_stat
ps aux # list processes: USER, PID, %CPU, %MEM, COMMAND
top / htop # live view of CPU and memory per process
lscpu # CPU details: cores, cache sizes (Linux)
df -h # disk space per filesystem
Annotated ps aux output (one line):
USER PID %CPU %MEM VSZ RSS STAT COMMAND
root 812 0.3 1.2 72540 9820 Ss /usr/sbin/sshd
^ ^ ^ ^
| | | +-- the program being run
| | +-- RSS: real RAM the process uses (KB)
| +-- PID: unique process id
+-- USER: the security context (which user it runs as)
The USER column is the security context, PID uniquely identifies the process, and RSS is the actual RAM it occupies.
Performance and behaviour come from how these four pieces interact.
The speed gap between tiers is enormous:
This is why "swapping to disk" (moving memory contents to disk when RAM runs low) tanks performance.
A process is a running program plus its state:
The operating system gives each process the illusion that it owns the whole machine. It does this through virtual memory: each process sees its own private address space.
A process can have several threads — independent execution paths that share the same memory.
Shared memory makes threads fast. It is also exactly why race conditions and data corruption happen: two threads can read and write the same data at the same time.
Process information is valuable for reconnaissance and privilege escalation:
ps on Linux, Task Manager on Windows).A process running as root (the all-powerful administrator on Linux) with a vulnerability is a path upward to higher privileges.
Concept track: instead of compilable C, here is a realistic, reproducible lab session you can run on your own Linux machine or container to see the storage tiers and processes. Run each command and read the comments.
# 1) How much RAM exists and how much is free (Linux).
# 'available' is what new programs can use without swapping.
free -h
# total used free shared buff/cache available
# Mem: 15Gi 4.2Gi 6.1Gi 0.3Gi 4.8Gi 10Gi
# Swap: 2.0Gi 0B 2.0Gi
# 2) CPU and its cache sizes (the fast volatile tiers live here).
lscpu | grep -E 'Model name|^CPU\(s\)|cache'
# Model name: Intel(R) Core(TM) i5 ...
# CPU(s): 8
# L1d cache: 256 KiB
# L2 cache: 2 MiB
# L3 cache: 8 MiB
# 3) Persistent storage: how big is the disk and how full?
df -h /
# Filesystem Size Used Avail Use% Mounted on
# /dev/sda1 234G 88G 134G 40% /
# 4) Processes: who is running what, and as which user?
# Sorted by memory use, top 6.
ps aux --sort=-%mem | head -n 6
# 5) Threads: a single process can hold many threads.
# Show thread count for every process (NLWP = number of threads).
ps -eo pid,nlwp,user,comm --sort=-nlwp | head -n 6
What this does. Step 1 shows the volatile RAM tier and the swap area on disk used when RAM runs low. Step 2 reveals the fastest tiers — CPU caches measured in KB/MB, far smaller than RAM. Step 3 shows the slow but persistent disk. Step 4 lists processes with their USER (security context) and memory use. Step 5 shows that one process (PID) can contain many threads (NLWP).
Expected output. Exact numbers depend on your machine, but you should see: RAM measured in GB, caches in KB/MB, disk in hundreds of GB, and a process list where the USER column is sometimes root and sometimes your own username. A browser or database process typically shows a high NLWP (many threads).
Edge cases. free is Linux-only; on macOS use vm_stat and top. In a minimal container, lscpu may report the host's CPU, and ps aux may show only a handful of processes because the container is isolated. None of these commands modify anything, so they are safe to run repeatedly.
Walking through the lab session and what each step reveals about the model:
| Step | Command | What it observes | Tier / concept |
|---|---|---|---|
| 1 | free -h |
total vs available RAM, plus swap | Volatile RAM; swap = RAM spilling to disk |
| 2 | lscpu | grep cache |
L1/L2/L3 cache sizes | Fastest volatile tiers, very small |
| 3 | df -h / |
disk capacity and usage | Slow, persistent tier |
| 4 | ps aux --sort=-%mem |
processes by memory, with USER | The process abstraction + security context |
| 5 | ps -eo ...,nlwp,... |
thread count per process | Threads share one process |
Trace through what you would see, step by step:
free -h prints two rows. The Mem row's available column is the headline number: it's how much a new program can claim before the system must swap. If available is near zero and Swap used is climbing, the machine is thrashing — copying memory to the slow disk tier.lscpu confirms the hierarchy's top: L1 is tens of KB, L2 a few MB, L3 several MB. Compare that to the GBs in step 1 — the fast tiers are thousands of times smaller than RAM. This is why the CPU can't just keep everything in cache.df -h / shows the disk in the hundreds of GB. Notice it dwarfs RAM in size but, from earlier, is hundreds of thousands of times slower to read.ps aux builds the picture of processes. Read it column by column: USER (who it runs as → its power), PID (its identity), %MEM/RSS (its footprint in RAM), COMMAND (the program). A line with USER=root is a process with full privileges; the same browser may appear as several lines (several processes), each a separate instance.ps -eo ...,nlwp,... adds the NLWP column = "number of light-weight processes" = threads. A value of 1 means a single-threaded process; a value like 40 on a browser tab process means 40 threads sharing that one process's memory — exactly the setup where race conditions become possible.Why the result is what it is. Each command queries the kernel's bookkeeping. The kernel is the component that creates these abstractions — it tracks every process, its owner, its memory mapping, and its threads. You are reading the same tables the OS uses to schedule and isolate everything.
Mistake 1 — Confusing a program with a process.
ps aux | grep chrome shows several PIDs from one program.Mistake 2 — Thinking "saved" always means "on disk."
fsync; this is why they keep write-ahead logs). Treat unsynced data as volatile.Mistake 3 — Assuming a single increment is atomic across threads.
# Two threads, shared counter, no protection
thread: counter = counter + 1 # read, add, write -- 3 steps
+1s can both read the same old value and one update is lost (a race condition).# Serialize access so only one thread touches counter at a time
thread: lock()
counter = counter + 1
unlock()
# or use an atomic increment provided by the language/runtime
Mistake 4 — Believing more RAM always means faster.
Because this is a conceptual lesson, "debugging" means diagnosing system behaviour rather than fixing compiler errors. Common situations and how to investigate them:
"My machine suddenly got slow."
top or htop and look at the memory line and per-process %MEM.available RAM (free -h) is near zero and swap is being used, you are thrashing: memory is spilling to the slow disk tier. Close memory-hungry processes or add RAM."My data disappeared after a crash."
"My multithreaded program gives different answers each run."
"ps shows the same program many times — is that a leak?"
ps -ef) to see if they're children of one launcher.Questions to ask when something doesn't behave:
Robustness and safety for this topic. This is a non-programming concept lesson, so the focus is on reasoning correctly about state, durability, and isolation rather than on C undefined behaviour. The same ideas, however, underpin the memory-safety rules you will meet in the C track later.
Authorization note. Inspecting processes and memory is fine on machines you own or are explicitly authorized to examine. Reading other users' or other systems' process and memory data without permission is not. Keep all experimentation on your own computer, a personal VM, or a container.
Concrete real-world uses
www-data) with many threads handling requests concurrently — the exact CPU/RAM/process/thread model from this lesson. The next lesson, What an operating system does, builds directly on this.Professional best-practice habits
Beginner rules:
top, free, df).Advanced rules:
Work through these in order; each builds on the last. They use observation and reasoning, not programming.
Beginner 1 — Map your own machine's tiers.
free -h (or vm_stat/Activity Monitor on macOS), lscpu (or system info), and df -h, record: total RAM, L1/L2/L3 cache sizes, and disk capacity.RAM: 16 GB | L1: 256 KB, L2: 2 MB, L3: 8 MB | Disk: 512 GB SSD.Beginner 2 — Program vs process count.
ps aux | grep -i <browser> | grep -v grep and count the distinct PIDs. Write down how many processes one program produced and which USER they run as.Intermediate 1 — Catch the swap.
htop (or top), open several memory-heavy apps. Record the moment available RAM drops and whether Swap used rises. Write 3-4 sentences explaining what the machine is doing and why it slows down.Intermediate 2 — Count the threads.
ps -eo pid,nlwp,user,comm --sort=-nlwp | head. Pick one process with NLWP = 1 and one with a high NLWP. In writing, explain what shared memory means for the multithreaded one and why a race condition could occur there.NLWP.NLWP = number of threads.Challenge — Reason through a lost update.
counter = counter + 1 once, starting from counter = 0, that ends with counter == 1 instead of 2. Then rewrite the sequence using a lock so the final value is correct, and show the new interleaving.Main concepts. Computers store data in a memory hierarchy — registers and cache (inside the CPU), then RAM, then disk — trading speed for size and persistence. Registers, cache, and RAM are volatile (lost on power-off); disk is persistent. A process is a running program with its own private virtual memory, open handles, environment, and a security context (the user it runs as); virtual memory is what keeps processes isolated. A thread is an execution path inside a process; threads share the process's memory, which makes them fast but enables race conditions.
Most important commands to observe these ideas. free -h (RAM + swap), lscpu (cache sizes), df -h (disk), ps aux (processes and their USER), ps -eo ...,nlwp (thread counts), top/htop (live view).
Common mistakes to avoid. Confusing a program with a process; assuming "saved" means "flushed to disk"; treating a counter increment as atomic across threads; thinking more RAM always means faster.
What to remember. Know which tier your data is in, whether it survives a power-off, how many processes (and as which user) are involved, and whether any state is shared between threads without protection. These four questions carry directly into the next lesson, What an operating system does, where you'll see how the OS schedules processes and manages this memory.