Process management (computing): Difference between revisions

Revision as of 16:53, 20 July 2024

Revision as of 20:56, 22 August 2024

Line 5:

== 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 could be executing the same program, 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 each can execute the same program-code. Such a program is said to be [[Reentrant (subroutine)|re-entrant]].{{Relevance inline|date=November 2023}} 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. A number of processes being executed over a period of time instead of at the same time is called [[Concurrent computing|concurrent execution]].{{cn|date=November 2023}}

A [[multiprogramming]] or [[Computer multitasking|multitasking]] OS is a system executing many processes concurrently. Multiprogramming requires that the processor be allocated to each process for a period of time and de-allocated 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 it can be restarted later as easily as possible.

Line 11:

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.

# A hardware [[interrupt]] occurs; for example, a key was pressed on the keyboard, or a timer runs out (used in [[preemption (computing)|pre-emptive multitasking]]).

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. 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 the 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 became aware that for much of the time that a computer was allocated to a single user, the processor was idle; when the user was entering information or debugging programs for example. [[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 30:

''t''_{''i'' (execution)} is the total execution time for the process; i.e. the time for CPU cycles plus I/O cycles to be carried out (executed) until completion of the process.

In fact, usually, the sum of all the processor time, used by ''N'' processes, rarely exceeds a small fraction of the time to execute any one of the processes;

: <math>\sum_{j=1}^{N} t_{j \, (\mathrm{processor})} < t_{i \, (\mathrm{execution}\!)}</math>

Line 40:

== Process creation ==

{{Original research|section|date=November 2023}}

Operating systems need some ways to create processes. In a very simple system designed for running only a single application (e.g., the controller in a microwave oven), it may be possible to have all the processes that will ever be needed be present when the system comes up. In general-purpose systems, however, some way is needed to create and terminate processes as needed during operation.<br />

There are four principal events that cause a process to be created:

* System initialization.

Line 48:

When an operating system is booted, typically several processes are created. Some of these are foreground processes, that interact with a (human) user and perform work for them. Others are [[background process]]es, which are not associated with particular users, but instead have some specific function. For example, one background process may be designed to accept incoming e-mails, sleeping most of the day but suddenly springing to life when an incoming e-mail arrives. Another background process may be designed to accept an incoming request for web pages hosted on the machine, waking up when a request arrives to service that request.

Process creation in UNIX and Linux areis done through [[fork (system call)|fork()]] or clone() system calls. There are several steps involved in process creation. The first step is the validation of whether the [[parent process]] has sufficient authorization to create a process. Upon successful validation, the parent process is copied almost entirely, with changes only to the unique process id, parent process, and user-space. Each new process gets its own user space.<ref>[http://sunnyeves.blogspot.com/2010/09/sneak-peek-into-linux-kernel-chapter-2.html "A Sneak-Peek into Linux Kernel - Chapter 2: Process Creation"]</ref>

Process creation in Windows is done through the CreateProcessA() system call. A new process runs in the security context of the calling process, but otherwise runs independently of the calling process. Methods exist to alter the security context in which a new processes runs. New processes are assigned identifiers by which thethey can be accessed. Functions are provided to synchronize calling threads to newly created processes.<ref>{{Cite web | url=https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa | title=CreateProcessA function (Processthreadsapi.h) - Win32 apps | date=9 February 2023 }}</ref><ref>{{Cite web | url=https://docs.microsoft.com/en-us/windows/win32/procthread/creating-processes | title=Creating Processes - Win32 apps | date=9 February 2023 }}</ref>

== Process termination ==

Line 63:

* Memory unavailable

* Bounds violation; for example: attempted access of (non-existent) 11th element of a 10-element array

* Protection error; for example: attempted to write to a read-only file

* [[Arithmetic]] error; for example: attempted division by zero

* Time overrun; for example: the process waited longer than a specified maximum for an event

* [[I/O]] failure

* Invalid instruction; for example: when a process tries to execute data (text)

Line 76:

== Two-state process management model ==

{{original research|date=November 2023}}

The [[operating system]]'s principal responsibility is into controllingcontrol the execution of [[process (computing)|processes]]. This includes determining the interleaving pattern for execution and allocation of resources to processes. One part of designing an OS is to describe the behaviourbehavior that we would like each process to exhibit. The simplest model is based on the fact that a process is either being executed by a processor or it is not. Thus, a process may be considered to be in one of two states, ''RUNNING'' or ''NOT RUNNING''. When the operating system creates a new process, that process is initially labeled as ''NOT RUNNING'', and is placed into a queue in the system in the ''NOT RUNNING'' state. The process (or some portion of it) then exists in [[main memory]], and it waits in the queue for an opportunity to be executed. After some period of time, the currently ''RUNNING'' process will be interrupted, and moved from the ''RUNNING'' state to the ''NOT RUNNING'' state, making the processor available for a different process. The dispatch portion of the OS will then select, from the queue of ''NOT RUNNING'' processes, one of the waiting processes to transfer to the processor. The chosen process is then relabeled from a ''NOT RUNNING'' state to a ''RUNNING'' state, and its execution is either begun if it is a new process, or is resumed if it is a process which was interrupted at an earlier time.

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.

Line 93:

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, 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.

Line 115:

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. So, 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 [[computer architecture]] may logically extend the mode bit{{Incomprehensible inline|date=November 2023}} to define areas of memory to be used when the processor is in kernel mode versus user mode. If the mode bit is set to kernel mode, the process executing in the processor can access either the kernel or user partition of the memory. However, if user mode is set, the process can reference only the user memory space. We{{Who|date=November 2023}} frequently refer to two classes of memory user space and system space (or kernel, supervisor, or protected space). In general, the mode bit extends the operating system's protection rights.{{Incomprehensible inline|date=November 2023}} The mode bit is set by the user mode trap instruction, {{original research span|date=November 2023|also called a [[Supervisor Call instruction]].}} This instruction sets the mode bit, and branches to a fixed ___location in the system space. Since only system code is loaded in the system space, only system code can be invoked via a trap.{{Incomprehensible inline|date=November 2023}} When the OS has completed the supervisor call, it resets the mode bit to user mode prior to the return.{{original research inline|date=November 2023}}

== 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]] 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.

== Requesting system services ==

Line 133:

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]] 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 users processes in kernel mode. Even procedure-based operating systemsystems usually find it necessary to include at least a few [[system process]]es (called [[daemon (computer software)|daemons]] in [[UNIX]]) to handle situationsituations whereby the machine is otherwise idle such as [[scheduling (computing)|scheduling]] and handling the network.{{cn|date=November 2023}}

== See also ==