INTRODUCTION
We are now about to embark on a detailed study of how operating system are designed and constructed. The most central concept in any operating system is the process: an abstraction of a running program. Everything else hinges on this concept, and it is important that the operating system designer (and student) have a thorough understanding of what a process is as possible.
Processes are one of the oldest and most important abstractions that operating system provide. They support the ability to have (pseudo) concurrent operation even there is only one CPU available. They turn a single CPU into multiple virtual CPUs. Without the process abstraction, modern computing could not exist. In this chapter we will go into considerable detail about processes.
PROCESS CONCEPT
A process is an entity that consists of a number of elements. Two essential elements of a process are program code (which may be shared with other processes that are executing the same program) and set of data (associated with that code).
It is an active entity that requires a set of resources, including a processor and special registers, to perform its function. A process is also called a task. It is a single instance of an executable program.
In a single-user system, the processor is busy only when the user is executing a job-at all the other times it is idle. Processor management in this environment is simple. However, when there are many users with many jobs on the system (this is known as a multiprogramming environment), the processor must be allocated to each job in a fair and efficient manner, which can be a complex task.
Program itself is not a process; a program is a passive entity, such as the contents of the file shared on the disk, whereas a process is an active entity with a program counter specifying the next instruction to execute and a set of associated resources.
Although, two processes may be associated with the same program, they are nevertheless considered as two separate execution sequences. For instance, several users may be running different copies of the mail program, or the same user may invoke many copies of the editor program. Each of this is a separate process, and although text sections are equivalent, the data section varies. It is also common to have a process that spawns (call another process) many process as it runs.
PROCESS STATES
We can characterize the behavior of an individual process by listing the sequence of instructions that execute for that process. Such a listing is referred to as a trace of the process. For example:
If there are three processes named process 1, process 2, and process 3. To each process operating system has allocated different times to execute,
Process 1 takes 12 seconds to execute.
Process 2 takes 4 seconds to execute.
Process 3 takes 12 seconds to execute.
FIGURE 2.1 Main memory with different processes
We assume that the operating system only allows a process to continue its execution for six seconds maximum after which it is interrupted.
FIGURE 2.2 Processes fetched by dispatcher
Here, first dispatcher will dispatch first process named process 1 and it will be given to processor to do execution of it, now after the completion of six second process 1 will be interrupted. So processor will execute only up to six seconds and remaining six second process will be kept back in queue (after process C). Now same apply for process 2 and process 3. After completing all processes for execution, again all remaining processes will be started for its remaining execution.
A Two-state Process Model
The operating system principal responsibility is controlling the execution of processes; this determines the interleaving pattern for execution and allocating resources to processes. The first step in designing an operating system is to control processes is to describe the behavior that we would like to processes to exhibit.
We can construct the simplest possible model by observing that, at any time a process is either being executed by a processor or not.
Process may be in one of the two states: Running or Not running. When the operating system creates a process it creates a Process Control Block (PCB) for the process and enters that process into the system in the Not running state. The process exists, is known to the operating system, and is waiting for an opportunity to execute. From time to time, the currently running program (process) will be interrupted and the dispatcher portion of the operating system will select some other process to run. The former process moves from the Running state to the Not running state, and one of the other processes moves to the Running state.
From this simple model, we can already begin to appreciate some of the design elements of the operating system. Each process must be represented in some way that the operating system can keep track of it. That is, there must be information relating to each process, including current state and location in memory, this is the PCB. Processes that are not running must be kept in some sort of queue waiting their turn to execute.
FIGURE 2.3 State Transition Diagram
FIGURE 2.4 Queuing Diagram
There is a single queue in which each entry is a pointer to the PCB of a particular process. Alternatively, the queue may consist of a linked list of data blocks in which each block represents one process.
We can describe the behavior of the dispatcher in terms of this queuing diagram. A process that is interrupted is transferred to the queue of waiting processes. Alternatively, if the process has completed or aborted, it is discarded (exits the system). In either case, the dispatcher then selects a process from the queue to execute.
A Five- State Model
If all processes were always ready to execute, then the queuing discipline suggested would be effective. The queue is a first-in-first-out list and the processor operates in round-robin fashion on the available processes (each process in the queue is given a certain amount of time, in turn, to execute and then return to queue, unless blocked).
Some processes in the Not running state are ready to execute, while others are blocked, waiting for an I/O operation to complete. Thus, using a single queue, the dispatcher could not just select the process at the oldest end of the queue. Rather, the dispatcher would have to scan the list looking for the process that is not blocked and that has been in the queue the longest.
A more natural way to handle this situation is to split the Not running state into two states: Ready and Blocked. For good measures we have added additional states that will prove useful.
FIGURE 2.5 Five state process model
1. New. A process that has just been created but has not yet been admitted to the pool of executable processes by the operating system. Typically, a new process has not yet been loaded into the main memory, although its process control clock (PCB) has been created.
2. Ready. A process that is prepared to execute when given the opportunity.
3. Running. Instructions are being executed. When a process gets a control from CPU plus other resources, it starts executing. The running process may require some I/O during execution. Depending on the particular scheduling policy of operating system, it may pass its control block to that process or operating system may schedule another process if one is ready to run.
4. Blocked/Suspend/wait. A suspend process lacks some resource other than CPU. Such processes are normally not considered for execution until the related suspending conditions are fulfilled. The running process becomes suspended by invoking I/O routines whose result it needs in order to proceed.
5. Exit/Terminate. When the process finally stops. A process terminates when it finishes executing its last statement. At that point in time, the process may return some data to its parent process. Sometimes there are additional circumstances when termination process can cause the termination of another process via an appropriate system call.
The New and Exit states are useful constructs for process management. The New state corresponding to a process that has just been defined. For example, if a new user attempts to log onto a time-sharing system or a new-batch job is submitted for execution, the operating system can define a new process in two stages. First the operating system performs the necessary housekeeping chores. An identifier is associated with the process. Any tables that will be needed to manage the process are located and built. At this point, the process is in the New state. This means that the operating system has performed the necessary actions to create the process but has not committed itself to the execution of the process. For example, the operating system may limit the number of processes that may be in the system for the reasons of performance or main memory limitation. While a process is in the New state, information concerning the process itself is not in main memory, and no space has been allocated for the data associated with that program. While the process is in the New state, the program remains in the secondary storage, typically disk storage.
Similarly, a process exits a system in two stages. First, a process is terminated when it reaches a natural completion point, when it aborts due to an unrecoverable error, or when another process with the appropriate authority causes the process to abort. Termination moves the process to the exit state. At this point, the process is no longer eligible for execution. The tables and other information associated with the job are temporarily preserved by the operating system, which provides time for auxiliary or support programs to extract any needed information. For example, an accounting program may need to record the processor time and other resources utilized by the process for billing purposes. Once these programs have extracted the needed information the operating system no longer needed to maintain any data relating to the process and the process is deleted from the system.
· Null à New. A new process is created to execute a program.
· New à Ready. The operating system will move a process form the new state to the ready state when it is prepared to take on an additional process. Most system set some limit based on the number of existing processes or the amount of virtual memory committed to existing processes.
· Ready à Running. When it is time to select a new process to run, the operating system chooses one of the processes in the ready state. This is the job of the scheduler or dispatcher.
· Running à Exit. The currently running process is terminated by the operating system if the process indicates that it has completed or if it aborts.
· Running à Ready. The most common reason for this transition is that the running process has reached the maximum allowable time for uninterrupted execution; virtually multiprogramming operating system impose this type of time discipline. There are several other alternatives causes for the transition, which are not implemented in all operating system of particular importance is the case in which the operating system assigns levels of priority to different processes. Suppose for example that process A is running at a given priority level, and process B, at a higher priority level is blocked, the operating system learns that the event upon which process B has been waiting has occurred, moving B to a ready state, than it can interrupt process A and dispatch process B. we say that the operating system preempted process A.
· Running à Blocked. A process is put in the blocked state if it requests something for which it must wait. When processes communicate with each other, a process may be blocked when it is waiting for another process to provide data or waiting for a message from another process.
· Blocked à Ready. A process in the blocked state it is moved to the ready state when the event for which it has been waiting occurs.
· Ready à Exit. In some systems, a parent may terminate a child process at any time. Also if a parent terminates, all child processes associated with that parent may be terminated.
Resource Used:
1. Operating System (By Galvin)
Compiled By: Chaudhary Amit V.
Comments
Post a Comment