A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
A process is formally a state machine transitioning between discrete states (new, ready, running, waiting, terminated) triggered by scheduling decisions and I/O completion. This model enables proof of correctness for scheduling algorithms and synchronization protocols.
You already know that a process is a program in execution and that processes move through states like ready, running, and waiting during their lifecycle. Process model formalization takes that intuition and makes it mathematically precise by treating the process as a finite state machine — the same concept you may recognize from automata theory, now applied to how an operating system manages running programs.
The formal model defines exactly five states — new, ready, running, waiting, and terminated — and specifies every legal transition between them. A process in the new state can only move to ready (once admitted by the OS). A ready process can only move to running (when the scheduler dispatches it). A running process can transition to waiting (if it requests I/O), back to ready (if preempted by the scheduler), or to terminated (if it finishes or is killed). No other transitions are permitted. This rigidity is the point: by constraining what can happen, you create something you can reason about formally.
Why does this matter? Because once you have a precise state machine, you can prove properties about scheduling algorithms and synchronization protocols. For example, you can prove that a particular scheduler will never leave a process in the ready state forever (no starvation), or that two processes will never be in the running state on the same CPU simultaneously. Without formalization, these are just hopes — with it, they become theorems. Think of it like the difference between saying "this bridge looks strong enough" and calculating the load it can bear using physics.
The formalization also reveals something subtle: the transitions are triggered by different actors. The OS scheduler controls ready-to-running and running-to-ready transitions. The process itself triggers running-to-waiting (by issuing a system call for I/O). Hardware triggers waiting-to-ready (when an I/O interrupt signals completion). Understanding who controls each transition is essential for designing correct context switches and preventing race conditions where two parts of the system disagree about a process's state.