What "running a program" really means

From unit 1, a program file sits on disk. Before the CPU can fetch its instructions, as in lesson 1-2, the OS has to load the program's code into RAM.

The fetch step of the fetch-decode-execute cycle reads from RAM, and disk is about a thousand times too slow to fetch from directly, so the OS first copies the program in.

That copying is a large part of what "launching" actually means. A program does not start executing where it lives, it starts executing from a copy.

Program versus process

These two words are not synonyms, and the difference is the key idea of this unit.

A program is a file on disk. python3 is a program, and so is your script. A process is a running instance of one: the code loaded into RAM, plus its own memory for variables, plus bookkeeping the OS keeps about it such as who started it, what files it has open, and where its program counter is.

This distinction is the working vocabulary of real operations. ps, kill, "the server runs four workers", "restart the process", and Docker containers are all statements about processes rather than programs. Get it wrong and a command such as kill seems mysterious. Get it right and it becomes obvious.

One program can be many processes. Open three terminal windows and run python3 in each, and there is one program on disk and three separate processes, each with its own memory. A variable set in one is invisible to the others.

The process table

The OS tracks every process in a process table, one entry per process holding its ID, owner, state, and more. The states are what matter most:

On a machine with 4 CPU cores and 300 processes, at most 4 are running at any instant, and almost everything else is ready or waiting.

That ratio is why a machine with hundreds of processes still feels responsive. Most processes are blocked on input they have not received yet, so they are costing nothing, and the scheduler in unit 6 only has to choose among the few that are actually ready.

The simulation below prints a toy process table with one dictionary per process.

A toy process table

One dictionary per process, in the spirit of what the OS keeps internally.

process_table = [
    {"pid": 101, "name": "browser", "state": "running"},
    {"pid": 102, "name": "music",   "state": "ready"},
    {"pid": 103, "name": "editor",  "state": "waiting"},
]
for p in process_table:
    print(p["pid"], p["name"], "->", p["state"])

Output

101 browser -> running
102 music -> ready
103 editor -> waiting

The editor is waiting because it is blocked, most likely on the next keystroke. It is not slow and it is not stuck, it simply has nothing to do until input arrives.

A real table has dozens of columns rather than three, including the owner, the memory footprint, the open file handles, and the saved program counter. The shape is the same: a list of records, one per process, that the kernel updates as processes change state.

Two runs of one script share nothing

Running the same Python script in two terminals, where script A sets total = 10, leaves script B seeing only whatever B computed itself.

Each process has completely separate memory. Process isolation means the OS gives every process its own private memory and the hardware rejects any access outside it, so neither process can see or touch the other's variables.

Same instructions, separate workspaces, much like two cooks following copies of one recipe in different kitchens.

Every one of those routes goes through the OS, which is the point. Isolation is not a limitation that got left in, it is the guarantee that makes running untrusted code on a shared machine possible at all.