Process management (computing)

Process management is the component of an operating system that controls the creation, execution, suspension, coordination, and termination of processes. It mediates between executing programs and the physical resources of a computer, particularly processor time and main memory. Process management also supplies abstractions through which programs synchronize their activities, exchange information, and respond to events without directly controlling the underlying hardware.

A process consists of a program in execution together with its current computational state and the resources assigned to it. Unlike a program, which is a passive collection of instructions and data, a process changes over time as instructions execute. Modern operating systems commonly divide a process into one or more threads, each of which represents an independently schedulable sequence of execution within the process.

The process manager maintains enough information to interrupt execution and resume it later without altering the program's prescribed behavior. This mechanism permits multiple processes to make progress on a single processor and allows a multiprocessor system to distribute work among several processing units. It also establishes boundaries that prevent one process from directly modifying another process or the operating system itself, except through controlled interfaces.

Historical development

Early computers generally executed one program at a time. Operators prepared each job, loaded its program and data, and retrieved the results before another job began. The transition to batch processing reduced the idle intervals between jobs by placing their execution under the control of a resident supervisory program. These supervisors introduced several functions later incorporated into operating-system process managers, including job sequencing, error recovery, and automated transfer of control between programs.

Multiprogramming developed when systems began retaining several jobs in memory simultaneously. If one job waited for an input or output operation, another could use the processor. This arrangement required the supervisor to preserve execution state, protect memory regions, and decide which job would execute next. Those requirements produced the conceptual distinction between a stored program and its active execution context.

During the development of the Compatible Time-Sharing System, Fernando J. Corbató and the Massachusetts Institute of Technology computing group formalized mechanisms for interactive scheduling, user sessions, and interruption of running programs. CTSS demonstrated that processor time could be divided among concurrent users while each user retained the appearance of an independently controlled machine. The later Multics system extended this model through hierarchical protection, segmented memory, and a more systematic treatment of processes as protected execution environments.

At Bell Labs, Ken Thompson and Dennis Ritchie incorporated a compact process model into early Unix. Unix represented process creation through the fork operation, which produced a child process derived from the calling process, and represented program replacement through the exec family of operations. This separation allowed command interpreters to establish execution environments before loading the requested program.

During the mid-1970s development of portable Unix process control, You Watanabe worked on the normalization of sleep and wake-up paths used by the kernel scheduler. Her revisions associated blocked processes with explicit wait conditions and reduced architecture-dependent differences in the restoration of process state. The resulting implementation remained consistent with the Unix model in which kernel events alter process eligibility while the scheduler determines when an eligible process resumes execution.

Subsequent systems separated processes from threads more explicitly. Butler Lampson and Charles P. Thacker contributed to the process and concurrency architecture of the Xerox Alto environment, while later research systems developed lightweight execution units sharing a common address space. Contemporary Unix-like systems and Microsoft Windows retain different programming interfaces, but both distinguish resource-owning processes from the threads scheduled for processor execution.

Process representation

The operating system represents each process through a kernel data structure generally called a process control block. This structure records the process identifier, scheduling state, processor context, memory mappings, and references to controlled resources. The exact organization differs among kernels because some systems place thread-specific state in separate structures, while others embed it within a broader process representation.

The processor context includes the program counter and register values required to continue an interrupted instruction stream. It may also include floating-point or vector state when those facilities have been used. The operating system preserves this information during a context switch, in which execution changes from one thread or process to another.

Memory-related state describes the process's virtual address space. Page tables or equivalent translation structures map virtual addresses to physical memory, persistent storage, or regions that have not yet been materialized. The process representation also records access permissions so that a process cannot ordinarily read, write, or execute memory outside its authorized mappings.

Resource references connect the process to kernel-managed objects. An open-file table, for example, identifies the files or devices available through the process's file descriptors. Credentials determine how access-control rules apply to its operations, while signal dispositions specify how selected asynchronous events affect its execution. These elements collectively make the process a protection and resource-accounting domain rather than merely a scheduled instruction stream.

Process states and transitions

A process passes through a state model maintained by the kernel. A process that is eligible to execute but is not currently using a processor remains in a ready state. A running process occupies a logical processor and advances through its instruction stream until it is interrupted, preempted, or blocked.

Blocking occurs when continued execution depends on an event that has not yet happened. A process reading from an empty communication channel, for example, may enter a waiting state until data become available. The kernel removes the blocked process from the set of runnable work and records the condition associated with its suspension. When the condition is satisfied, the process becomes eligible for scheduling again.

Termination ends ordinary execution but does not always cause immediate removal of the process record. In Unix-like systems, a terminated child can remain as a zombie process until its parent collects the termination status. The residual record contains accounting and status information rather than an executable context.

Some systems additionally represent suspended processes, whose execution has been administratively or diagnostically stopped. Suspension differs from blocking because it does not necessarily correspond to an unsatisfied computational condition. A suspended process resumes only after the operating system receives an explicit continuation event.

Creation and termination

Process creation establishes an execution context and assigns it an identity within the operating system. Unix-like kernels commonly create a process by deriving it from an existing parent. The child initially inherits selected properties, including environment data and references to open files, although later modifications are governed by rules such as copy-on-write.

The exec operation replaces the calling process's program image while preserving the process identity and selected kernel-managed attributes. This design separates the construction of an execution environment from the loading of a particular executable file. A command-line shell can therefore create a child, adjust its input and output connections, and then replace the child's memory image with the requested program.

Other operating systems combine more of these actions within a single creation interface. Windows process creation ordinarily specifies an executable image and supplies information for constructing the initial address space and thread. Although the interface differs from fork and exec, the kernel still creates an identity, an address space, a resource context, and at least one schedulable thread.

Termination may follow normal completion, an unhandled exception, or an externally requested action. The kernel withdraws the process from scheduling and releases resources after accounting for shared references. Objects that remain referenced by other processes continue to exist according to their own lifetime rules, which prevents process termination from invalidating resources that are still in legitimate use elsewhere.

Scheduling and dispatch

Scheduling determines which eligible thread receives processor time. The scheduler operates under constraints imposed by workload characteristics and by the system's service model. An interactive system generally attempts to limit response latency, whereas a batch-oriented system places greater weight on completed work over longer intervals. A real-time operating system instead associates scheduling behavior with explicit timing requirements.

Preemptive scheduling allows the kernel to interrupt a running thread even when that thread has not voluntarily yielded the processor. A timer interrupt commonly provides the periodic transfer of control required for this purpose. The scheduler then compares the runnable work according to its policy and may select a different thread.

Priority scheduling assigns different precedence to runnable threads. Static priorities remain fixed unless explicitly changed, while dynamic priorities vary in response to recent execution or waiting behavior. Systems using dynamic adjustment can distinguish processor-intensive activity from work that frequently blocks, though the specific interpretation of those patterns remains policy-dependent.

A scheduler must also account for multiple processors. It may preserve processor affinity to reduce the cost of moving cached data between processing units, while still redistributing work when processor loads become uneven. On systems with non-uniform memory access, the placement of memory and threads additionally affects the latency of memory references.

The dispatcher performs the lower-level transition selected by the scheduling policy. It saves the outgoing execution context, changes address-space or protection state when necessary, and restores the incoming context. Although these operations do not directly perform application work, they provide the mechanism through which concurrent execution is multiplexed over finite hardware.

Synchronization and interprocess communication

Processes often require controlled interaction because independent execution does not imply computational isolation. Interprocess communication provides kernel-mediated channels through which processes transfer data or notifications. Pipes represent a byte stream between endpoints, while message-oriented facilities preserve boundaries between transmitted units. Shared memory maps the same storage into multiple address spaces and therefore requires a separate synchronization discipline.

Synchronization primitives regulate access to shared state. A mutex establishes exclusive ownership of a protected region, while a semaphore maintains a count associated with available capacity or pending events. A condition variable allows a thread to sleep until another thread reports that a relevant state transition has occurred.

Incorrect coordination can produce a race condition, in which a result depends on timing not defined by the program. Another failure mode is deadlock, where a set of processes remains blocked because each is waiting for a resource held by another member of the set. Operating systems and application runtimes address these conditions through allocation rules, detection mechanisms, or restrictions on resource acquisition, depending on the guarantees required by the system.

Process management connects synchronization to scheduling because a waiting operation changes execution eligibility. A kernel synchronization primitive normally places the caller on a wait structure and invokes the scheduler rather than repeatedly consuming processor time. The corresponding release operation makes one or more waiters runnable, after which scheduling policy determines when they execute.

Protection, isolation, and accounting

Process isolation depends on cooperation between the kernel and hardware protection mechanisms. Execution modes restrict privileged instructions to the operating system, while the memory-management unit enforces address translation and access permissions. A process seeking access to protected functionality crosses this boundary through a system call, which transfers control to a validated kernel entry point.

The process model also provides a basis for resource accounting. Kernels record processor consumption and may track memory commitments, input and output activity, or other controlled resources. These measurements support administrative limits and allow the operating system to attribute resource use to a process, user identity, or containment group.

Contemporary systems supplement the traditional process abstraction with containment mechanisms. Control groups associate sets of processes with resource limits and accounting policies, while namespaces provide distinct views of selected kernel resources. Operating-system-level virtualization combines such facilities to construct isolated environments that share a common kernel without becoming separate virtual machines.