Process management (computing)

A process is a program in execution, and an integral part of any modern-day operating system (OS).

In any modern operating system, there can be more than one instance of a program loaded in memory at the same time.

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.

Multiprogramming requires that the processor be allocated to each process for a period of time and de-allocated or issued at an appropriate moment.

There are two 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 stopping of one process and starting (or restarting) of another process is called a context switch or context change.

A thread may be viewed as a sub-process; that is, a separate, independent sequence of execution within the code of one process.

To overcome this inefficiency, multiprogramming is now implemented in modern operating systems such as Linux, UNIX and Microsoft Windows.

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: Operating systems need some ways to create processes.

Process creation in UNIX and Linux is done through fork() or clone() system calls.

Functions are provided to synchronize calling threads to newly created processes.

This includes determining the interleaving pattern for execution and allocation of resources to processes.

The process (or some portion of it) then exists in main memory, and it waits in the queue for an opportunity to be executed.

From this model, we can identify some design elements of the OS: 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.

A key design decision for any OS function is determining whether it should be implemented in the kernel.

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 mechanism and authentication process required during the call can be relatively resource-intensive.

There are two techniques by which a program executing in user mode can request the kernel's services: Operating systems are designed with one or the other of these two facilities, but not both.

First, assume that a user process wishes to invoke a particular target system 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[jargon]), to the entry point of the function which is to be invoked.

Meanwhile, the user process waits for the result of the service request with a message receive operation.

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.

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 user processes in kernel mode.