Process management (computing)
≈ 6 min read
Names in other languages
No names in other languages are held for this entry yet.
Article bodies are English and are not machine-translated. A name in another language is not a translation of the article.
A process is a program in execution, and an integral part of any modern-day operating system (OS). The OS must allocate resources to 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, The OS must maintain a data structure for each process, which describes the state and resource ownership of that process, and which enables the operating system to exert control over each process.
A process is a program in execution, and an integral part of any modern-day operating system (OS). The OS must allocate resources to 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, The OS must maintain a data structure for each process, which describes the state and resource ownership of that process, and which enables the operating system to exert control over each process. ==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 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 for example, when a user was entering information or debugging programs the processor was 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 1 , t 2 , ..., t N , then the total time, t uni , to service the N processes (consecutively) of all N users would be: t uni = t 1 + t 2 + ... + t N . However, because each process consumes both CPU cycles and I/O cycles, the time which each process actually uses the CPU is a very small fraction of the total execution time for the process. So, for process i: t i (processor) ≪ t i (execution) where t i (processor) is the time process i spends using the CPU, and 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; \sum_{j=1}^{N} t_{j \, (\mathrm{processor})} Therefore, in uni-programming systems, the processor lays idle for a considerable proportion of the time. To overcome this inefficiency, multiprogramming is now implemented in modern operating systems such as Linux, UNIX and Microsoft Windows. This enables the processor to switch from one process, X, to another, Y, whenever X is involved in the I/O phase of its execution. Since the processing time is much less than a single job's runtime, the total time to service all N users with a multiprogramming system can be reduced to approximately: t multi = max(t 1 , t 2 , ..., t N ) ==Three-state process management model== Although the two-state process management model is a perfectly valid design for an operating system, the absence of a BLOCKED state means that the processor lies idle when the active process changes from CPU cycles to I/O cycles. This design does not make efficient use of the processor. The three-state process management model is designed to overcome this problem, by introducing a new state called the BLOCKED state. This state describes any process which is waiting for an I/O event to take place. In this case, an I/O event can mean the use of some device or a signal from another process. The three states in this model are: RUNNING: The process that is currently being executed. READY: A process that is queuing and prepared to execute when given the opportunity. BLOCKED: A process that cannot execute until some event occurs, such as the completion of an I/O operation. 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 policy used for the Low Level 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.
Text derived from https://en.wikipedia.org/w/index.php?oldid=1357104725 under CC BY-SA 4.0; modifications have been made.