Processes & the Process Abstraction

a program vs a process

Here is a useful pair of pictures. A program is a sheet of music: a static set of instructions, sitting there whether or not anyone plays it. A process is a performance of that music: a living, time-bound event with a current note, a tempo, and a player. The same sheet of music can be performed many times, in many rooms, at the same moment. That is exactly the relationship between a program and a process.

Concretely, a program is a passive file on disk: a sequence of machine instructions plus initial data, stored as an executable. It does nothing on its own. A process is an active entity: when the OS loads that program into memory, gives it an address space, sets the program counter to the first instruction, and lets the CPU run it, the program becomes a process. The process has state that the program does not have on disk: a current program counter, register values, a stack of function calls, a heap of allocated memory, and open files. Running the same program twice creates two processes with two separate sets of this state.

Why labor this point? Because almost every later idea depends on it. The OS schedules processes, not programs. It protects one process's memory from another, not one program file from another. A bug that crashes one process need not crash another running the same program. And the word 'running' belongs only to a process: a program does not 'run', it is run, by being turned into a process.

/usr/bin/python3 is a program (a file). Typing python3 in three terminals starts three processes from that one file; each has its own variables, and quitting one does not affect the others.

The file is the program (passive); each running instance is a process (active).

A common slip is to say 'I have two programs running.' What you usually mean is two processes. There is only ever one program file; running it produces processes.

Also called
passive vs active靜態程式與動態行程