Process management (computing)

Source: Wikipedia, the free encyclopedia.

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 OS to exert control over each process.

Multiprogramming

In any modern operating system there can be more than one instance of a

re-entrant.[relevant?] The 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 execution.[citation needed
]

A

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.

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:

  1. The process issues a system call (sometimes called a software interrupt); for example, an I/O request occurs requesting to access a file on hard disk.
  2. A hardware interrupt occurs; for example, a key was pressed on the keyboard, or a timer runs out (used in pre-emptive multitasking).

The stopping of one process and starting (or restarting) of another process is called a

client–server systems and in software run on multi-processor
systems.

How multiprogramming increases efficiency

A common trait observed among processes associated with most computer programs, is that they alternate between

Computer scientists
observed that 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 t1, t2, ..., tN, then the total time, tuni, to service the N processes (consecutively) of all N users would be:

tuni = t1 + t2 + ... + tN.

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:

ti (processor)ti (execution)

where

ti (processor) is the time process i spends using the CPU, and
ti (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;

Therefore, in uni-programming systems, the processor lay idle for a considerable proportion of the time. To overcome this inefficiency, multiprogramming is now implemented in modern operating systems such as

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

tmulti = max(t1, t2, ..., tN)

Process creation

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.
There are four principal events that cause a process to be created:

  • System initialization.
  • Execution of process creation system call by a running process.
  • A user request to create a new process.
  • Initiation of a batch job.

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 processes, 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 are done through 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.[1]

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 the can be accessed. Functions are provided to synchronize calling threads to newly created processes.[2][3]

Process termination

There are many reasons for process termination:

  • Batch job issues halt instruction
  • User logs off
  • Process executes a service request to terminate
  • Error and fault conditions
  • Normal completion
  • Time limit exceeded
  • Memory unavailable
  • Bounds violation; for example: attempted access of (non-existent) 11th element of a 10-element array
  • Protection error; for example: attempted write to read-only file
  • Arithmetic error; for example: attempted division by zero
  • Time overrun; for example: 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)
  • Privileged instruction
  • Data misuse
  • Operating system intervention; for example: to resolve a deadlock
  • Parent terminates so child processes terminate (cascading termination)
  • Parent request

Two-state process management model

The

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.
  • The queuing of NON RUNNING processes

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

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

Each process in the system is represented by a data structure called a Process Control Block (PCB), or Process Descriptor in Linux.

Process Identification: Each process is uniquely identified by the user's identification and a pointer connecting it to its descriptor.

Process Status: This indicates the current status of the process; READY, RUNNING, BLOCKED, READY SUSPEND, BLOCKED SUSPEND.

Process State: This contains all of the information needed to indicate the current state of the job.

Accounting: This contains information used mainly for billing purposes and for performance measurement. It indicates what kind of resources the process has used and for how long.

Processor modes

Contemporary

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
on its behalf.

The computer architecture may logically extend the mode bit[incomprehensible] 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?] 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] The mode bit is set by the user mode trap instruction, also called a Supervisor Call instruction.[original research?] 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] When the OS has completed the supervisor call, it resets the mode bit to user mode prior to the return.[original research?]

The Kernel system concept

The parts of the

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

There are two techniques by which a program executing in user mode can request the

kernel
's services:

user mode and then returns control to the user process; thus simulating a normal procedure return.[citation needed
]

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 OS process. The send function serves the same purpose as the trap; that is, it carefully checks the message, switches the 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 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,

UNIX) to handle situation whereby the machine is otherwise idle such as scheduling and handling the network.[citation needed
]

See also

References

  1. ^ "A Sneak-Peek into Linux Kernel - Chapter 2: Process Creation"
  2. ^ "CreateProcessA function (Processthreadsapi.h) - Win32 apps". 9 February 2023.
  3. ^ "Creating Processes - Win32 apps". 9 February 2023.

Sources