The lifetime of a process can be divided into a set of states, each with certain characteristics that describe the process.
1. The process is currently executing in user mode.
2. The process is currently executing in kernel mode.
3. The process is not executing, but it is ready to run
as soon as the scheduler chooses it. Many processes may be in this state,
and the scheduling algorithm determines which one will execute next.
4. The process is sleeping. A process puts itself to
sleep when it can no longer continue executing, such as when it is waiting
for I/O to complete.
Because a processor can execute only one process at a time, at most one process may be in states 1 and 2.
The process states described above give a static view of a process, but processes move continuously between the states according to well-defined rules. A state transition diagram is a directed graph whose nodes represent the states a process can enter and whose edges represent the events that cause a process to move from one state to another. State transitions are legal between two states if there exists an edge from the first state to the second.
Figure 2.6 shows the state transition diagram for the process states defined above.
Several processes can execute simultaneously in a time-shared manner, as stated earlier, and they may all run simultaneously in kernel mode. If they were allowed to run in kernel mode without constraint, they could corrupt global kernel data structures. By prohibiting arbitrary context switches and controlling the occurrence of interrupts, the kernel protects its consistency.
The kernel allows a context switch only when a process moves from the state "kernel running" to the state "asleep in memory." Processes running in kernel mode cannot be preempted by other processes; therefore the kernel is sometimes said to be non-preemptive, although the system does preempt processes that are in user mode. The kernel maintains consistency of its data structures because it is non-preemptive, thereby solving the mutual exclusion problem — making sure that critical sections of code are executed by at most one process at a time.