Process management (computing): Difference between revisions

Revision as of 10:19, 13 October 2024

Latest revision as of 17:48, 13 July 2025

(21 intermediate revisions by 15 users not shown)

Line 2:

{{OS}}

A process is a program in execution, and an integral part of any modern-day [[operating system]] (OS). The OS must allocate resources to [[process (computing)|processes]], enable processes to share and exchange information, protect the resources of each process from other processes and enable synchronization among processes. To meet these requirements, theThe OS must maintain a [[data structure]] for each process, which describes the state and resource ownership of that process, and which enables the OSoperating system to exert control over each process.

== Multiprogramming ==

In any modern operating system, there can be more than one instance of a [[computer program|program]] loaded in memory at the same time. For example, more than one user couldcan be executing the same program, with each user having separate copies of the program loaded into memory. With some programs, it is possible to have one copy loaded into memory, while several users have shared access to it so that they can each execute the same program-code. Such a program is called [[Reentrant (subroutine)|re-entrant]].{{Relevance inline|date=November 2023}} TheAt a given instant, the [[central processing unit|processor]] at any instant can only be executing one instruction from one program, but several processes can be sustained over a period of time by assigning each process to the processor at intervals while the remainder become temporarily inactive. The execution of multiple processes over a period of time, rather than simultaneously, is calledknown as concurrent execution.

A [[multiprogramming]] or [[Computer multitasking|multitasking]] OSO.S. is a systemOperating System that can execute many processes concurrently. Multiprogramming requires that the processor be allocated to each process for a period of time and de-allocated or issued at an appropriate moment. If the processor is de-allocated during the execution of a process, it must be done in such a way that itthe process can be restartedrestart later as easilyefficiently as possible.

There are two possible ways for an OS to regain control of the processor during a program's execution in order for the OS to perform de-allocation or allocation:

# The process issues a [[system call]] (sometimes called a ''software [[interrupt]]''); for example, an I/O request occurs requesting to access a file on a hard disk.

Line 17:

==How multiprogramming increases efficiency==

A common trait observed among processes associated with most computer programs is that they alternate between [[CPU]] cycles and [[I/O]] cycles. For the portion of the time required for CPU cycles, the process is being executed; i.e.and is occupying the CPU. During the time required for I/O cycles, the process is not using the processor. Instead, it is either waiting to perform Input/Output, or is actually performing Input/Output. An example of this is reading from or writing to a file on disk. Prior to the advent of [[multiprogramming]], [[computers]] operated as single-user systems. Users of such systems quickly become aware that for much of the time that a computer was allocated to a single user{{snd}}for example, the processor was idle; when thea user was entering information or debugging programs{{snd}}the forprocessor examplewas idle. [[Computer scientists]] observed that the overall performance of the machine could be improved by letting a different process use the processor whenever one process was waiting for input/output. In a ''uni-programming system'', if ''N'' users were to execute programs with individual execution times of ''t''₁, ''t''₂, ..., ''t''_''N'', then the total time, ''t''_uni, to service the ''N'' processes (consecutively) of all ''N'' users would be:

: ''t''_uni = ''t''₁ + ''t''₂ + ... + ''t''_''N''.

Line 78:

From this model, we can identify some design elements of the OS:

* The need to represent, and keep track of each process.

* The state of a process.

* The queuing of ''NON RUNNING'' processes

Line 91:

At any instant, a process is in one and only one of the three states. For a single processor computer, only one process can be in the ''RUNNING'' state at any one instant. There can be many processes in the ''READY'' and ''BLOCKED'' states, and each of these states will have an associated queue for processes.

Processes entering the system must go initially into the ''READY'' state, and processes can only enter the ''RUNNING'' state via the ''READY'' state. Processes normally leave the system from the ''RUNNING'' state. For each of the three states, the process occupies space in the main memory. While the reason for most transitions from one state to another might be obvious, some may not be so clear.

* '''''RUNNING → READY:''''' The most common reason for this transition is that the running process has reached the maximum allowable time for uninterrupted execution; i.e. time-out occurs. Other reasons can be the imposition of priority levels as determined by the [[scheduling (computing)|scheduling]] policy used for the Low Level [[Scheduling (computing)|Scheduler]], and the arrival of a higher priority process into the READY state.

* '''''RUNNING → BLOCKED:''''' A process is put into the ''BLOCKED'' state if it requests something for which it must wait. A request to the OS is usually in the form of a system call, (i.e. a call from the running process to a function that is part of the OS code). For example, a process might become ''BLOCKED'' if it is requesting a file from disk or a saving a section of code or data from memory to a file on disk.

== Process description and control ==

Line 112:

Contemporary [[Processor (computing)|processors]] incorporate a mode bit to define the execution capability of a program in the processor. This bit can be set to ''[[kernel mode]]'' or ''[[user mode]]''. Kernel mode is also commonly referred to as ''[[supervisor mode]]'', ''monitor mode'' or ''[[ring 0 (computer security)|ring 0]]''.

In kernel mode, the processor can execute every instruction in its hardware repertoire, whereas in user mode, it can only execute a subset of the instructions. Instructions that can be executed only in kernel mode are called kernel, privileged, or protected instructions to distinguish them from the user mode instructions. For example, [[I/O]] instructions are privileged. SoAs such, if an [[application software|application]] program executes in user mode, it cannot perform its own [[I/O]]. Instead, it must request the OS to perform [[I/O]] on its behalf.

== The Kernel system concept ==

{{Repetition section|date=November 2023}}<!-- This appears to be a second section in a row describing CPU modes. -->

The parts of the [[operating system|OS]] that are critical to its correct operation execute in [[kernel mode]], while other [[software]] (such as generic system software) and all application programs execute in [[user mode]]. This fundamental distinction is usually the irrefutable distinction between the operating system and other [[system software]]. The part of the system executing in the kernel supervisor state is called the [[kernel (computer science)|kernel]], or nucleus, of the [[operating system]]. The kernel operates as trusted software, meaning that when it was designed and implemented, it was intended to implement protection mechanisms that could not be covertly changed through the actions of untrusted software executing in user space. Extensions to the OS execute in [[user mode]], so the OS does not rely on the correctness of those parts of the system software for the correct operation of the OS. Hence, a fundamental design decision for any function to be incorporated into the OS is whether it needs to be implemented in the kernel. If it is implemented in the kernel, it will execute in kernel (supervisor) space, and have access to other parts of the kernel. It will also be trusted software by the other parts of the kernel. If the function is implemented to execute in [[user mode]], it will have no access to kernel data structures. However, the advantage is that it will normally require very limited effort to invoke the function. While kernel-implemented functions may be easy to implement, the trap mechanism and authentication at the time of the call are usually relatively expensive. The kernel code runs fast, but there is a large performance overhead in the actual call. This is a subtle, but important point.

The critical parts of the [[operating system|OS]] run in [[kernel mode]], while other [[software]] (such as system utilities and application programs) run in [[user mode]]. This serves as the fundamental distinction between the OS and other [[system software]]. The part of the system executing in the kernel mode is called the [[kernel (computer science)|kernel]], or nucleus, of the OS. The kernel is designed as trusted software, meaning it implements protection mechanisms that cannot be covertly modified by untrusted software running in user mode. Extensions to the OS operate in [[user mode]], so the core functionality of the OS does not depend on these extensions for its correct operation.

A key design decision for any OS function is determining whether it should be implemented in the kernel. If implemented in the kernel, it operates in kernel mode, gaining access to other parts of the kernel and being trusted by them. Conversely, if the function executes in [[user mode]], it lacks access to kernel data structures but requires minimal effort to invoke. Although functions implemented in the kernel can be straightforward, the [[trap (computing)|trap mechanism]] and authentication process required during the call can be relatively resource-intensive. While the kernel code itself runs efficiently, the overhead associated with the call can be significant. This is a subtle but important distinction.

== Requesting system services ==

Line 123 ⟶ 126:

* [[Message passing]]

[[Operating systems]] are designed with one or the other of these two facilities, but not both. First, assume that a [[user mode|user process]] wishes to invoke a particular target system function. For the [[system call]] approach, the user process uses the trap instruction. The idea is that the system call should appear to be an ordinary procedure call to the application program; the [[operating system|OS]] provides a library of user functions with names corresponding to each actual system call. Each of these stub functions contains a trap to the OS function. When the application program calls the stub, it executes the trap instruction, which switches the [[CPU]] to [[kernel mode]], and then branches (indirectly through an OS table{{Technical inline|date=November 2023}}), to the entry point of the function which is to be invoked. When the function completes, it switches the processor to [[user mode]] and then returns control to the user process;, thus simulating a normal procedure return.{{cn|date=November 2023|reason=Unclear why this called 'simulating'.}}

In the [[message passing]] approach, the user process constructs a message, that describes the desired service. Then it uses a trusted send function to pass the message to a trusted [[operating system|OS]] [[process (computing)|process]]. The send function serves the same purpose as the trap; that is, it carefully checks the message, switches the [[Microprocessor|processor]] to kernel mode, and then delivers the message to a process that implements the target functions. Meanwhile, the user process waits for the result of the service request with a message receive operation. When the OS process completes the operation, it sends a message back to the user process.

The distinction between the two approaches has important consequences regarding the relative independence of the OS behavior, from the application process behavior, and the resulting performance. As a rule of thumb, [[operating system|operating systems]] based on a [[system call]] interface can be made more efficient than those requiring messages to be exchanged between distinct processes. This is the case, even though the system call must be implemented with a trap instruction; that is, even though the trap is relatively expensive to perform, it is more efficient than the message-passing approach, where there are generally higher costs associated with the process [[multiplexing]], message formation and message copying. The system call approach has the interesting property that there is not necessarily any OS process. Instead, a process executing in [[user mode]] changes to [[kernel mode]] when it is executing kernel code, and switches back to user mode when it returns from the OS call. If, on the other hand, the OS is designed as a set of separate processes, it is usually easier to design it so that it gets control of the machine in special situations, than if the kernel is simply a collection of functions executed by usersuser processes in kernel mode. Even procedureProcedure-based operating systems usually find it necessary to include at least a few [[system process]]es (called [[daemon (computer software)|daemons]] in [[UNIX]]) to handle situations whereby the machine is otherwise idle such as [[scheduling (computing)|scheduling]] and handling the network.{{cn|date=November 2023}}

== See also ==

Line 142 ⟶ 145:

* Process Management Models, Scheduling, UNIX System V Release 4:

* Modern Operating Systems, Andrew Tanenbaum, Prentice Hall, (2nd Edition, 2001).

* Operating System Concepts, Silberschatz & Galvin & Gagne (httphttps://codex.cs.yale.edu/avi/os-book/OS9/slide-dir/), John Wiley & Sons, (6th Edition, 2003)

{{Operating System}}