Process Management in Operating System | OS Tutorials

In early computer systems, only one program could be executed at a time, and current-day computer systems allow multiple programs to be loaded into memory and to be executed concurrently. So, in operating system process management, a technique is used to manage multiple programs at a time.

What is Process Management

Controlling multiple running programs at a time in an operating system is known as process management. It includes managing the input and output of programs, the next program coming in execution, temporary data of the stack, and the global variables. Let’s see in detail how process management is done in an operating system.

Process Definition

The term “process” was first used by the designers of MULTICS in the 1960s. Since then, the term process has been used somewhat interchangeably with ‘task’ or ‘job’.

The process has been given many definitions, for instance

• A program in Execution.
• An asynchronous activity.
• The ‘animated spirit’ of a procedure in execution.
• The entity to which processors are assigned.
• The ‘dispatchable’ unit.

and many more definitions have been given.

• As we can see from above, there is no universally agreed-upon definition, but the definition “Program in Execution” seems to be most frequently used.
• Basically, a process is an instance of a program in execution. All multiprogramming operating systems, from single-user systems to mainframes that can support thousands of users, are built around the concept of the process.
• A process is the entity that can be assigned to and executed on a processor.
• A unit of activity characterized by the execution of a sequence of instructions, a current state, and an associated set of system resources.
• A process will need certain resources to accomplish its task, such as CPU time, memory files, and I/O devices.
• These resources are allocated to the process either when it is created or while it is executing.
• Since a process is the smallest unit of work individually schedulable by an operating system.
• Such a system consists of a collection of processes: Operating system processes execute System code, and user processes execute user code. All these processes may execute concurrently.
• The Operating system is responsible for the following activities in connection with process management
  1. The Creation and Deletion of both user and system processes.
  2. The Scheduling of Processes.
  3. Provision of a mechanism for synchronization.
  4. Provision of a mechanism for Communication.
  5. Provision of a mechanism for Deadlock Handling for processes.

Process Vs Program

Process is not the same as a program. Process generally includes the current activity by the value of the program counter and the process stack containing temporary data, and also a data section containing global variables. A Program is a passive entity, such as the contents of a file stored on disk, whereas a process is an active entity. Many people can run the same program, and each copy of this program corresponds to a distinct process. Although two processes may be associated with the same program.

Sometimes, it may say that a relation between process and program is the same beast with a different name, or when this beast is sleeping (not executing), it is called program, and when it is executing becomes process. Process is not the same as program. A process is more than a program code. A process is an ‘active’ entity as opposed to a program, which is considered a ‘passive’ entity. As we all know, a program is an algorithm expressed in some suitable notation (e.g., programming language). Being passive, a program is only a part of the process. Process, on the other hand, includes:

1. Current value of Program Counter (PC)
2. Contents of the processor’s registers
3. Value of the variables
4. The process stacks (SP), which typically contain temporary data such as subroutine parameters, return address, and temporary variables.
5. A data section that contains global variables.

A process is the unit of work in a system. In the process model, all software on the computer is organized into several sequential processes. A process includes PC, registers, and variables. Conceptually, each process has its own virtual CPU. In reality, the CPU switches back and forth among processes. The rapid switching back and forth is called multiprogramming.

Process States

When a process comes into execution, it changes its state. The state of a process is defined as a part by the current activity of that process. Each process may be in one of the following states.

1. New – The Process is being created
2. Running – Instructions are being executed.
3. Waiting/Blocked – The process is waiting for some event to occur (such as an I/O completion or reception of a signal)
4. Ready – In this state, the process is waiting to be assigned to a processor through a short-term scheduler.
5. Terminated – In this state, the process has finished execution.

The state transition diagram corresponding to the states discussed above is shown in Figure 1. These state names are arbitrary, and they vary across operating systems. However, the states that they represent are found on all systems.

Only one process can be running on any processor at any instant. Many processes may be ready and waiting. The Operating system, therefore, provides for at least seven basic system calls or routines. Some of these are callable by the programmer, whereas others are used by the Operating System itself in manipulating various things. These are summarized below:

(i)    Enter  (Presses_id) :             ->      new
(ii)   Enter  (Presses_id) :   new       ->      new
(iii)  Enter  (Presses_id) :   Ready     ->      new
(iv)   Enter  (Presses_id) :   Running   ->      new
(v)    Enter  (Presses_id) :   Running   ->      new
(vi)   Enter  (Presses_id) :   Blocked   ->      new
(vii)  Enter  (Presses_id) :   Running   ->      new

For each system call, if the process ID is supplied as a parameter, it carries out the process state transition.

The Process Model

• A process is an instance of a program in execution. An intention to activate an executable program (compiled and linked) is announced to the operating system by means of a specialized command, such as RUN, or a system call provided for that purpose.
• The Operating system responds by creating a process. It is an activity that consists of the creation and initialization of operating system data structures for monitoring and controlling the progress of the related process.
• Process is a dynamic concept that refers to a program in execution, undergoing frequent state and attribute changes. An executable program, on the other hand, is a static process template that may give rise to one or more processes.
• In this model, all the runnable software on the computer, sometimes including the operating system, is organized into several sequential processes, or just processes.
• In Figure 2, a computer is multiprogramming with four programs in memory.

• In Figure 2, four processes, each with its own flow of control, are shown, and each one is running independently of the others. There is only a physical program counter.
• When each process runs, its logical program counter is loaded into the real program counter. When it is finished, the physical program counter is saved in the process stored logical program counter in memory.
• In Figure 2, over a long time interval, all the processes have made progress, but at any given instant, only one process is actually running.
• If a program is running twice, it counts as two processes.

Process Creation

• A Procèss may create several new processes via a create-process system call, during execution.
• The creation process is called a parent process, whereas the new processes are called the children of that process.
• Each of these new processes may in turn create other processes, forming a tree of processes as shown in Figure 3.

Reasons for Process Creation

• When an operating system is booted, typically several processes are created. Some of these processes interact with users and perform work for them. While some are not associated with a particular user, but instead have some specific function.
• Process Spawning – When the OS creates a process at the explicit request of another process, the action is referred to as process spawning.
• Traditionally, the OS created all processes in a way that was transparent to the user or application program. However, it can be useful to allow one process to cause the creation of another.
• When a process creates a new process, two possibilities exist in terms of execution:-
  1. The parent continues to execute concurrently with its children.
  2. The parent waits until some or all of its children have terminated.
• There are also two possibilities in terms of the address space of the new process:-
  1. The Child process is a duplicate of the parent process.
  2. The Child process has a program loaded into it.
• In UNIX, there is only one system call to create a new process, i.e., fork. This call creates an exact clone of the calling process.
• After the fork, the two processes, the parent and the child, have the same memory image, the same environment strings, and the same open files.
• This mechanism allows the parent process to communicate easily with its child process.
• The return code for the fork is zero for the new (child) process, whereas the (nonzero) process identifiers of the child are returned to the parent.
• The execve system call is used after a fork by one of the two processes to replace the process’s memory space with a new program.
• The execve system call loads a binary file into memory and starts its execution. In this way, the two processes are able to communicate.

Process Termination

• After a process has been created, it starts running and does whatever its job is.
• A process terminates when it finishes executing its last statement and asks the operating system to delete it by using the exit system call (in UNIX) and Exit Process (in WINDOWS).
• At that point, the process may return data in the form of output to its parent process via the wait system call.
• All the resources allocated to the process, including physical and virtual memory, I/O buffers, and open files, are deallocated by the operating system.
• Reasons for termination of any process:
• There are generally four conditions, which may result in process termination, these are:
  1. Normal Exit
  2. Error Exit
  3. Fatal Error
  4. Killed by another process
• Normal Exit is done, because processes have done their work (as discussed above using exit and exit process system call).
• Error Exit is done when the process discovers any fatal error. For example, if any program compiled by the programmer that did not exist, then the compiler simply exits. Screen-oriented interactive processes generally do not exist when given bad parameters. Instead, they pop up a dialog box and ask the user to try again.
• Fatal Error is an error caused by the process, often due to a program bug. For example, executing an illegal instruction, referencing nonexistent memory, or dividing by zero.
• Killed by another Process, in which a process might terminate by executing a system call telling the operating system to kill some other process. In UNIX, this call is kill, and in Win32, it is Terminate Process.
• In some systems, when a process terminates, all processes it created are immediately killed as well (Not in UNIX and Windows).
• There are additional circumstances when termination occurs. A process can cause the termination of another process via an appropriate system call like abort.
• Usually, such a system call can be invoked by only the parent of the process that is to be terminated.

Cascading Termination – Many systems do not allow a child to exist if its parent has terminated. In such a system, if a process terminates (either normally or abnormally), then all its children must also be terminated. This phenomenon is referred to as cascading termination and is normally initiated by the operating system.

Process Hierarchies

When a process creates another process, the parent process and child process continue to be associated in certain ways. Normally, the operating system allows a process to have offspring. The child process can itself create more processes, forming a process hierarchy. Process hierarchies are shown in Figure 4.

A question may arise: How is this process hierarchy normally implemented by the operating system?

The Operating system maintains a separate pointer chain to link the related PCBs to represent the process. In UNIX, a process and all of its children and further descendants together form a process group. When a user sends a signal from the keyboard, the signal is delivered to all members of the process group currently associated with the keyboard. Each process individually can catch the signal, ignore the signal, or take the default action.

Windows has no concept of a process hierarchy. All processes are equal. When a process is created, the parent is given a special token (called a handle) that it can use to control the child. However, it is free to pass this taken to some other process, thus invalidating the hierarchy. Processes in UNIX cannot disinherit their children.

Context Switching

In a multiprogramming system, switching the CPU from one program to another involves saving the state of the old process and loading the saved state for the new process. This task is known as a context switch. Context switch time is pure overhead, because the system does no useful work while switching.

Figure 5 shows the CPU switches from one process to another. The speed of switching varies from machine to machine, depending on the memory speed, the number of registers, and the existence of special instructions.

While context switching, the kernel saves the context of the currently running thread and resumes the context of the next thread that is scheduled to run. When a kernel preempts a thread, its context is saved. Once the preempted thread is scheduled to run again, its context is restored, and it continues as if it had never stopped.

The kernel allows context switch to occur under the following circumstances:

1. Thread Exits.
2. The thread time slice has expired, and a trap is generated.
3. The thread put itself into a debug or stop state.
4. The thread returns to user mode from a system call.
5. If a kernel thread has a higher priority than the running thread, it can preempt the current running thread. Only user threads can be preempted.

Figure 6 below shows that before the context switch, process A was running

At the time of context switch, the operating system stores the state of the CPU registers for process A (as shown in step (i)), restores (loads) the already saved registers of process B onto the CPU registers (as shown in step (ii)), and starts executing process B (step (iii)).

Since processes A and B can both be in the memory, this context switch does not require any swapping, thereby saving the time-consuming I/O operations. The process of switching is very fast, and therefore, the user thinks that he is the only ones using the whole machine.

Process Implementation

To implement the process model, the operating system maintains a table (an array of structures), called the process table, with one entry per process.

This entry contains important information about the process state, including its program counter, stack pointer, memory allocation, the states of its open files, scheduling information, and everything else about the process that must be saved when the process is switched from running to ready or blocked state, so that it can be restarted later. Table 2 shows some of the key fields in a typical system.

Interrupt Vector – With each I/O class, a location is associated, which is called the interrupt vector. It contains the address of interrupt service procedures.

Process Control Block

• Each Process is represented in the operating system by a process control block (PCB), also called a task control block.
• The Process control block is the most important data structure in an OS,
• Each process control block contains all the information about a process that is needed by the OS.
• The blocks are read and/or modified by virtually every module in the OS, including those involved with scheduling, resource allocation, interrupt processing, and performance monitoring and analysis.
• A PCB is shown in Figure 7.

It contains many pieces of information associated with a specific process, including these:

1. Process State: The state of a process could be any of new, ready, running, waiting, halted, and so on.
2. Program Counter: The Counter indicates the address of the next instruction to be executed for this process.
3. CPU Registers: The Registers vary in number and type, depending on the computer architecture. CPU registers may include the accumulator, Index Registers, Stack Pointers, and general-purpose registers. Along with the program counter, the state information must be saved when an interrupt occurs, to allow the process to be continued correctly. Several routines with the OS will need access to information in process control blocks. The Provision of direct access to these tables is not difficult. Each process is equipped with a unique ID, and this can be used as an index into a table of pointers to the process control block.
4. CPU Scheduling Information: This information includes a process priority, a pointer to scheduling queues, and any other scheduling parameters.
5. Memory Management Information: This information may include the value of the base and limit registers, the page tables, or the segmented table, depending on the memory system used by the OS.
6. Accounting Information: The information includes the amount of CPU and real time used, time limits, account numbers, job or process numbers, and so on.
7. I/O status Information: The information includes the list of I/O devices allocated to the process, the list of open files, and so on.

The PCB simply serves as the repository for any information that may vary from process to process.

Drawbacks of PCB

The problem in PCB is not associated with access but rather protection. Two problems present themselves:

1. A bug in a single routine, such as a timer interrupt handler, could damage the process control block (PCB), which could destroy the system’s ability to manage the affected processes.
2. A design change in the structure or semantics of the process control block could affect a number of modules in the OS.

These problems are addressed by requiring all routines in the OS to go through a handler routine, the only job of which is to protect the process control block.