Therefore, the detailed process/PCB portion below is presented using standard Operating Systems terminology rather than claiming that those missing details came from the supplied Unit-I file.
A process is a program in execution. A program stored on secondary storage is a passive entity, whereas a process is an active entity whose instructions are being executed by the CPU.
A process consists of the program code and the execution-related information required by the operating system. During execution, a process changes from one state to another depending on CPU scheduling, I/O requests and completion of execution.
In a multiprogramming or multitasking system, several processes can be kept in memory. When one process waits for an I/O operation, the CPU can be assigned to another process. This improves CPU utilization. The supplied material describes this behaviour in multiprogramming systems.
1. Program Code / Text Section – contains the instructions of the program.
2. Data Section – contains global and static data.
3. Heap – used for dynamically allocated memory.
4. Stack – stores local variables, function calls and related execution information.
5. Program Counter – contains the address of the next instruction to be executed.
6. CPU Registers – contain the current execution information of the process.
A process normally passes through the following five major states:
1. New
The process is being created.
2. Ready
The process is prepared to execute and is waiting for allocation of the CPU.
3. Running
The CPU is currently executing instructions belonging to the process.
4. Waiting / Blocked
The process cannot continue until some event occurs, commonly the completion of an I/O operation.
5. Terminated
The process has completed execution or has been terminated by the operating system.
New → Ready:
After the operating system creates and initializes the process, it is placed in the ready state.
Ready → Running:
The CPU scheduler selects a ready process and the dispatcher gives it the CPU.
Running → Ready:
A running process may be preempted when its time slice expires or another scheduling decision requires the CPU.
Running → Waiting:
When the process requests I/O or waits for some event, it cannot continue executing and enters the waiting state.
Waiting → Ready:
After the requested I/O operation or event is completed, the process becomes ready again.
Running → Terminated:
When the process completes its execution or calls for termination, it enters the terminated state.
A Process Control Block (PCB) is an operating-system data structure that stores important information about a particular process.
The OS uses the PCB to manage and control the process throughout its lifetime. During a context switch, the process's execution information can be saved in its PCB and later restored when the process executes again.
A PCB generally contains the following information.
1. Process Identification Information
Contains information used to identify the process.
Process ID (PID)
Parent Process ID (PPID)
User identification information
The PID uniquely identifies a process.
2. Process State
Stores the current state of the process, such as:
New
Ready
Running
Waiting
Terminated
3. Program Counter
Contains the address of the next instruction that the process should execute.
4. CPU Registers
Contains the values of CPU registers associated with the process.
These values are important when the process is stopped and later resumed.
5. CPU Scheduling Information
Contains information required by the scheduler, such as:
Process priority
Scheduling queue information
Time-slice information
Scheduling parameters
6. Memory-Management Information
Contains information about the memory allocated to the process, such as:
Page tables
Segment information
Base and limit information
Address-space information
7. Accounting Information
Contains information about resource usage, such as:
CPU time used
Process execution time
User identification
Job/account information
8. I/O and File Information
Contains information about resources being used by the process, including:
Open files
Allocated I/O devices
Pending I/O operations
The PCB is important because it allows the operating system to:
1. Identify each process.
2. Maintain the current process state.
3. Save and restore CPU execution information.
4. Perform CPU scheduling.
5. Manage process memory.
6. Track I/O and file resources.
7. Perform context switching.
8. Maintain accounting and resource-usage information.
The OS keeps process information in process-management data structures, while CPU scheduling determines which ready job should execute.
Process creation is the mechanism by which the operating system creates a new process for executing a program or task.
A process can create another process. The process that creates the new process is called the parent process, while the newly created process is called the child process.
This creates a hierarchy of processes.
Thus, processes can form a process tree.
1. Process Creation Request
A parent process requests the operating system to create a new process.
Examples of process-creation mechanisms include:
fork() in UNIX/Linux
CreateProcess() in Windows
2. Allocation of PCB
The operating system creates a new Process Control Block for the child process.
3. Assignment of PID
A unique Process Identifier (PID) is assigned to the new process.
4. Allocation of Memory
The operating system creates the required address space and allocates memory resources for the child.
5. Loading the Program
The program instructions and required data are prepared in memory for execution.
6. Initialization
The OS initializes:
Process state
Program counter
CPU registers
Scheduling information
Memory information
I/O information
7. Placement in Ready Queue
After initialization, the child process becomes ready for execution and is placed in the appropriate scheduling queue.
The parent process is the process that creates another process.
The parent and child processes may execute:
Sequentially
Concurrently
For example, after creating a child, the parent may continue execution while the child executes independently. Alternatively, the parent may wait for the child to finish.
In UNIX/Linux, fork() is commonly used to create a child process, while the parent can use wait()/waitpid() to wait for the child's completion.
When a child process is created, the relationship between the parent and child determines how resources are handled.
The child may receive resources from its parent depending on the operating-system implementation.
1. Shared Resources
Parent and child may share certain resources such as:
Open files
System resources
Certain communication resources
2. Inherited Resources
Some resources or attributes may be inherited from the parent.
For example:
The exact resource-sharing mechanism depends on the operating system.
In typical UNIX process creation, a child inherits aspects of the parent's execution environment, including resources such as open files, while maintaining its own process identity.
A common process-creation sequence is:
The fork() operation creates the child process. The child can then use exec() to replace its process image with another program.
Process termination occurs when a process finishes execution or is explicitly stopped by the operating system or another process.
When a process terminates, the operating system must release the resources allocated to that process.
1. Normal Completion
A process terminates normally after successfully completing its assigned task.
A process may execute the exit() system call to request normal termination.
2. Error Condition
A process may terminate because of an error from which it cannot recover.
Examples include:
Invalid memory access
Fatal programming error
Segmentation fault
Other unrecoverable execution errors
Such termination is generally considered abnormal termination.
3. Parent Terminates the Child
A parent process may explicitly terminate one of its child processes.
This can occur when:
The child has exceeded its allocated resources.
The task assigned to the child is no longer required.
The parent is terminating and the operating system does not allow the child to continue.
These are standard reasons for parent-initiated child termination.
4. Cascading Termination
In some operating systems, if a parent terminates, its child processes may also be terminated.
This is called cascading termination.
When a process terminates, the operating system performs resource cleanup.
1. Process execution is stopped.
2. Memory allocated to the process is released.
3. Open resources are closed/released.
4. I/O resources are released.
5. Process information is removed from active process-management structures.
6. The PCB is eventually deallocated.
7. The termination status may be made available to the parent process.
The operating system deallocates the resources associated with a terminated process and removes its PCB.
A process is a program in execution.
The operating system manages processes using structures such as the PCB.
The five major process states are New, Ready, Running, Waiting and Terminated.
The PCB contains PID, process state, program counter, CPU registers, scheduling information, memory-management information, accounting information and I/O/file information.
A process that creates another process is the parent, and the newly created process is the child.
Parent and child may execute concurrently or the parent may wait for the child.
A child may inherit or share selected resources with its parent.
A process can terminate normally after completing its task or abnormally because of an error.
A parent may terminate a child if the child exceeds allocated resources, its task is no longer required, or the parent is terminating.
When a process terminates, the OS deallocates its resources and eventually removes its PCB.
Symmetric Multiprocessing (SMP) is a system in which all processors are peers. Each processor can execute a copy of the operating system and communicate with the other processors when necessary.
1. All processors are equal peers.
2. Each processor can execute operating-system code.
3. Processors share system resources.
4. Multiple processes can execute simultaneously.
5. With n CPUs, at most n processes can run simultaneously.
6. Shared data structures can be used to distribute work properly among processors.
The supplied material gives Encore version of UNIX for the Multimax computer as an example of an SMP system.
Concurrent processing is a computing model in which multiple processors execute instructions simultaneously for better performance. Tasks can be divided into smaller parts and assigned to processors.
The Unit-II material discusses three concurrent-processing environments:
1. Multiprogramming
2. Multiprocessing
3. Distributed Processing
In a multiprogramming environment, multiple tasks are shared by one processor. The operating system switches the CPU between tasks so that while one task is waiting, another task can use the CPU.
If P1 is waiting for I/O, the CPU can execute P2 instead.
The material states that multiprogramming keeps several jobs in memory and switches the CPU to another job when the current job waits for I/O.
A computer running:
Web browser
Music player
Text editor
can switch the CPU between these programs.
In a multiprocessing environment, two or more processors are used with shared memory. A common virtual address space is used by all processors, and tasks can execute concurrently on different processors.
Processes can therefore execute at the same time on different processors.
A server with four CPUs can execute four independent CPU-intensive processes simultaneously.
In distributed processing, two or more computers are connected through a communication network or high-speed bus. Unlike multiprocessing, there is no shared memory between the computers; each computer has its own local memory. Processes communicate by exchanging messages.
A university may have separate computers for:
Library server
Examination server
Database server
Student portal server
These computers communicate through the campus network.
| Feature | Multiprogramming | Multiprocessing | Distributed Processing |
|---|---|---|---|
| Processors | One | Two or more | Two or more computers |
| Memory | Single system memory | Shared memory | Each computer has local memory |
| Execution | CPU switches among tasks | Processes execute simultaneously | Tasks distributed among computers |
| Communication | Through OS/CPU | Through shared memory | Through messages/network |
| Main purpose | Better CPU utilization | Parallel execution | Resource sharing and distributed execution |
| Example | Multiple applications on one CPU | Multi-core server | Network of campus servers |
CPU scheduling is the process of deciding which process from the ready queue should be allocated the CPU. The short-term scheduler selects a ready process and allocates the CPU to it.
The effectiveness of a scheduling algorithm can be evaluated using:
1. CPU Utilization – keeping the CPU as busy as possible.
2. Throughput – number of processes completed per unit time.
3. Turnaround Time – time from process submission to completion.
4. Waiting Time – time spent waiting in the ready queue.
5. Response Time – time from submission of a request until the first response.
FCFS schedules processes according to their arrival order. The process that arrives first gets the CPU first.
Given:
| Process | Burst Time |
|---|---|
| P1 | 24 ms |
| P2 | 3 ms |
| P3 | 3 ms |
Arrival order:
P1 → P2 → P3
P1 = 0 ms
P2 = 24 ms
P3 = 27 ms
Average waiting time:
These are the exact example values given in the Unit-II material.
Very simple.
Easy to implement.
Processes are handled in arrival order.
No starvation caused by priority differences.
Long process can make short processes wait for a long time.
Produces convoy effect.
CPU and device utilization can become lower than possible when short processes wait behind a long process.
Batch systems, where simple sequential processing is more important than quick response.
In SJF, the process with the shortest next CPU burst is selected first.
There are two versions:
1. Non-preemptive SJF
2. Preemptive SJF / Shortest Remaining Time First (SRTF)
Once a process receives the CPU, it continues until its CPU burst is completed.
| Process | Burst Time |
|---|---|
| P1 | 6 ms |
| P2 | 8 ms |
| P3 | 7 ms |
| P4 | 3 ms |
Order:
P4 → P1 → P3 → P2
P4 = 0 ms
P1 = 3 ms
P3 = 9 ms
P2 = 16 ms
Average waiting time:
This is the example given in the Unit-II material.
Gives low average waiting time.
Efficient when CPU burst times can be estimated.
The material states that SJF is optimal for minimum average waiting time for a given set of processes.
CPU burst time must be estimated.
Long processes may wait for shorter processes.
In preemptive SJF, if a new process arrives whose CPU burst is shorter than the remaining time of the currently running process, the current process is preempted. This is called Shortest-Remaining-Time-First (SRTF).
| Process | Arrival Time | Burst Time |
|---|---|---|
| P1 | 0 | 8 |
| P2 | 1 | 4 |
| P3 | 2 | 9 |
| P4 | 3 | 5 |
At time 0, P1 starts.
At time 1, P2 arrives. P1 has 7 ms remaining, while P2 needs only 4 ms, so P1 is preempted and P2 executes.
The source gives the average waiting time as 6.5 ms for this example.
Better response to newly arriving short processes.
Lower average waiting time than many other methods.
Efficient for short CPU-bound jobs.
More context switches.
Long processes may experience starvation.
Requires estimation of CPU burst times.
In Priority Scheduling, each process is assigned a priority number. The CPU is allocated to the process with the highest priority. In the supplied material, a smaller integer represents higher priority.
It can be:
Preemptive
Non-preemptive
| Process | Burst Time | Priority |
|---|---|---|
| P1 | 10 | 3 |
| P2 | 1 | 1 |
| P3 | 2 | 4 |
| P4 | 1 | 5 |
| P5 | 5 | 2 |
Priority order:
P2 → P5 → P1 → P3 → P4
The supplied example gives an average waiting time of 8.2 ms.
Important processes can be executed first.
Suitable when different processes have different levels of importance.
Can be implemented as preemptive or non-preemptive.
A low-priority process may wait for a very long time or may never execute.
Aging gradually increases the priority of a waiting process as time passes.
Round Robin is a preemptive scheduling algorithm mainly designed to give each process a fair share of CPU time.
Each process receives a small unit of CPU time called a time quantum. After the quantum expires, the process is preempted and placed at the end of the ready queue.
Given:
| Process | Burst Time |
|---|---|
| P1 | 24 ms |
| P2 | 3 ms |
| P3 | 3 ms |
Time quantum:
q = 4 ms
The supplied material gives an average waiting time of 5.66 ms for this example.
1. Fair CPU allocation.
2. Good response time for interactive processes.
3. No process has to wait indefinitely when the ready queue continues to rotate.
4. Suitable for time-sharing systems.
If q is large:
If q is too small:
The source explicitly states that large q approaches FIFO, while a small q can cause excessive context-switch overhead.
| Algorithm | Preemptive? | Main Advantage | Main Problem | Suitable Area |
|---|---|---|---|---|
| FCFS | No | Simple and easy | Convoy effect | Batch |
| SJF | No | Minimum average waiting time | Starvation / burst prediction | Batch |
| SRTF | Yes | Good waiting time | More context switches | Short interactive jobs |
| Priority | Both | Important jobs execute first | Starvation | Priority-based systems |
| Round Robin | Yes | Fairness and good response | Context-switch overhead | Interactive / time-sharing |
SJF is highly suitable
Batch systems generally contain jobs that can be processed without immediate user interaction.
SJF is preferred when CPU burst times can be estimated because:
Short jobs finish quickly.
Average waiting time is minimized.
Throughput can be improved.
The source explicitly states that SJF gives the minimum average waiting time for a given set of processes.
FCFS is also suitable when simplicity and arrival order are more important, but its convoy effect can reduce utilization.
Best choice:
SJF → Batch processing
For interactive/time-sharing systems, response time is very important. The source defines response time as the time from submission of a request until the first response is produced.
Round Robin gives each process a small time quantum and then moves it to the end of the ready queue.
Best choice:
Round Robin → Interactive / Time-sharing systems
For real-time systems, the most important requirement is that critical tasks receive CPU service within their required time constraints.
The supplied material distinguishes:
Hard Real-Time
A critical task must be completed within a guaranteed amount of time.
Soft Real-Time
Critical processes should receive priority over less important processes.
Therefore, among the algorithms discussed, Priority Scheduling is the most directly suitable for soft real-time requirements because it allows critical processes to receive higher priority.
For hard real-time systems, however, the supplied Unit-II material does not specify FCFS, SJF, Priority, or Round Robin as a guaranteed-deadline algorithm. Therefore, it would be incorrect to claim from this source alone that one of these four algorithms guarantees hard real-time deadlines. The key requirement stated by the source is the guaranteed completion time.
Best choice among the four listed algorithms:
Priority Scheduling → Soft real-time systems
Hard real-time → A dedicated deadline-based real-time scheduling method is required; the supplied material does not name one.
FCFS: Simple, but suffers from convoy effect.
SJF: Selects the shortest CPU burst and provides minimum average waiting time.
SRTF: Preemptive version of SJF; a shorter arriving process can preempt the current process.
Priority: Highest-priority process gets CPU; aging solves starvation.
Round Robin: Each process gets a time quantum, making it suitable for interactive systems.
Batch: SJF is the strongest choice when burst times are known/estimated.
Interactive: Round Robin is the strongest choice because of fair CPU sharing and response time.
Soft real-time: Priority Scheduling is suitable because critical processes can receive higher priority.
Hard real-time: Requires guaranteed timing; the supplied material does not specify one of these four algorithms as providing that guarantee.
Multilevel Queue Scheduling is a CPU scheduling technique in which the ready queue is divided into several separate queues. Processes are permanently assigned to a particular queue based on properties such as process type, priority, or memory requirements. Each queue can have its own scheduling algorithm.
Different processes may have different requirements. For example:
Interactive processes require fast response.
Batch processes can tolerate longer waiting.
System processes may need higher priority.
The source specifically gives the division between foreground (interactive) and background (batch) processes as an example.
The supplied material also gives a five-queue example:
These five categories are directly given in the Unit-II material.
1. Ready queue is divided into multiple queues.
2. Each process is permanently assigned to one queue.
3. Assignment can be based on process type, priority, memory size, etc.
4. Each queue may use a different scheduling algorithm.
Q1: System processes
Q2: Interactive processes
Q3: Batch processes
A system might give Q1 the highest priority and Q3 the lowest priority.
Multilevel Feedback Queue (MLFQ) scheduling is more flexible than multilevel queue scheduling because a process can move between different queues. Aging can also be implemented using this movement.
There are three queues:
Q0 → Time quantum = 8 ms
Q1 → Time quantum = 16 ms
Q2 → FCFS
A new process first enters Q0.
If the process does not finish within 8 ms in Q0, it is moved to Q1. If it still does not finish after receiving another 16 ms, it is preempted and moved to Q2.
The MLFQ scheduler is defined by:
1. Number of queues
2. Scheduling algorithm for each queue
3. Method for deciding when to upgrade a process
4. Method for deciding when to demote a process
5. Method for deciding which queue a process enters when it needs service.
| Feature | Multilevel Queue | Multilevel Feedback Queue |
|---|---|---|
| Queue assignment | Permanent | Can change |
| Process movement | ❌ Cannot move between queues | ✅ Can move between queues |
| Flexibility | Less flexible | Highly flexible |
| Aging | Not naturally implemented through movement | Can be implemented through movement |
| Classification | Based on process type/priority etc. | Based on process behavior and scheduling rules |
| Scheduling algorithms | Each queue can have its own algorithm | Each queue can have its own algorithm |
| Complexity | Relatively simple | More complex |
| Example | System → Interactive → Batch | Q0 → Q1 → Q2 |
| Suitable for | Clearly classified process groups | Systems with changing process requirements |
Multilevel Queue:
> Process stays in its assigned queue.
Multilevel Feedback Queue:
> Process can move between queues.
Multilevel Queue Scheduling is simpler and suitable when processes can be permanently classified into groups.
Multilevel Feedback Queue Scheduling is more flexible because processes can move between queues, allowing the scheduler to adapt to process behavior and implement aging.
Multiple-Processor Scheduling deals with scheduling processes when more than one CPU is available. The supplied material emphasizes that CPU scheduling becomes more complex when multiple CPUs are available.
The scheduler must decide which process should run on which processor.
A multiprocessor system may contain homogeneous processors, meaning the processors are similar in capability.
Load sharing attempts to distribute processes among processors so that the workload is balanced.
Before balancing:
The source identifies load sharing as an important consideration in multiple-processor scheduling.
In asymmetric multiprocessing, only one processor accesses the system data structures, which reduces the need for data sharing between processors.
With multiple CPUs, the scheduler has more decisions to make because it must distribute processes among several processors. The source explicitly notes that scheduling becomes more complex when multiple CPUs are available.
One CPU should not be overloaded while another remains idle.
Bad:
Good:
When processors share system data structures, coordination is required. Asymmetric multiprocessing can reduce this issue because only one processor accesses the system data structures.
The scheduler must keep available processors busy while avoiding excessive scheduling overhead.
Real-time scheduling is used when processes have timing requirements.
The supplied material divides real-time systems into:
1. Hard real-time systems
2. Soft real-time systems
In a hard real-time system, a critical task must be completed within a guaranteed amount of time.
Consider an aircraft control system:
Missing the required timing constraint can be unacceptable.
In a soft real-time system, critical processes should receive priority over less important processes.
A multimedia/video application may give higher priority to processing an incoming audio/video stream than to a background task.
Dispatch latency is an important issue in real-time scheduling.
It represents the delay involved between a real-time event/process becoming ready and the actual execution of that process.
The supplied material specifically includes dispatch latency as part of real-time scheduling.
The major challenge in a hard real-time system is guaranteeing that critical tasks complete within their required time.
Critical processes must receive appropriate priority, particularly in soft real-time systems.
The scheduler and dispatcher must respond quickly to events. Excessive dispatch latency can delay the execution of a critical process.
A real-time system needs predictable execution rather than simply maximizing average CPU performance.
| Feature | Multiple-Processor Scheduling | Real-Time Scheduling |
|---|---|---|
| Main concern | Efficient use of multiple CPUs | Meeting timing requirements |
| Main objective | Distribute workload effectively | Complete critical tasks on time |
| Major challenge | Scheduling complexity | Timing/deadline constraints |
| Important concept | Load sharing | Dispatch latency |
| Processor issue | Multiple CPUs | Can operate on one or multiple CPUs |
| Important technique | Load sharing / multiprocessing | Priority and timing-aware scheduling |
| Failure concern | CPU imbalance / inefficient utilization | Missing required response time |
Divides the ready queue into separate queues, and processes are permanently assigned to a queue. Each queue may use a different scheduling algorithm.
Allows processes to move between queues. It is more flexible and can implement aging.
Becomes more complex when multiple CPUs are available. Important issues include homogeneous processors, load sharing, and asymmetric multiprocessing.
Focuses on satisfying timing requirements. Hard real-time systems require guaranteed completion within a specified time, while soft real-time systems give critical processes higher priority. Dispatch latency is an important challenge.
CPU scheduling is the process of deciding which process from the ready queue should be allocated the CPU. The operating system uses scheduling algorithms to select the next process for execution.
The main criteria used to evaluate CPU scheduling algorithms are:
1. CPU Utilization
2. Throughput
3. Turnaround Time
4. Waiting Time
5. Response Time
CPU utilization means keeping the CPU as busy as possible.
The CPU should spend maximum time executing useful processes rather than remaining idle.
The value may range from 0% to 100%. The supplied material states that in a real system it should generally range from 40% to 90%.
Suppose:
Total time = 100 ms
CPU busy = 80 ms
Higher CPU utilization is generally better.
Throughput is the number of processes completed per unit of time.
Suppose 10 processes are completed in 5 seconds.
A good scheduling algorithm should complete more processes in less time.
Turnaround time is the total time taken from the submission of a process until its completion.
It includes:
Time waiting to enter memory
Time waiting in the ready queue
CPU execution time
I/O time
Process arrives = 0 ms
Process completes = 20 ms
Lower turnaround time is better.
Waiting time is the amount of time a process spends waiting in the ready queue for the CPU.
If P2 waits for 8 ms before receiving the CPU:
Lower waiting time is better.
For:
P1 = 24 ms
P2 = 3 ms
P3 = 3 ms
with arrival order P1 → P2 → P3:
P1 waiting = 0 ms
P2 waiting = 24 ms
P3 waiting = 27 ms
The supplied material uses this example to show the convoy effect in FCFS.
Response time is the time from when a request is submitted until the first response is produced. It is particularly important in a time-sharing environment.
It is important to note that response time is measured up to the first response, not until the entire output is completed.
Therefore:
Lower response time is better, especially for interactive systems.
| Criterion | Meaning | Desired Result |
|---|---|---|
| CPU Utilization | Percentage of time CPU remains busy | Maximum |
| Throughput | Processes completed per unit time | Maximum |
| Turnaround Time | Submission to completion time | Minimum |
| Waiting Time | Time spent waiting in ready queue | Minimum |
| Response Time | Time until first response | Minimum |
The CPU scheduler, also called the short-term scheduler, selects one process from the processes in memory that are ready to execute and allocates the CPU to it.
The ready queue does not necessarily have to be a FIFO queue. It can be implemented as a FIFO queue, priority queue, tree, or unordered linked list.
The scheduler selects a process from the ready queue.
It determines which ready process should receive the CPU.
The selection is based on an algorithm such as:
FCFS
SJF
Priority
Round Robin
Multilevel Queue
Multilevel Feedback Queue
In preemptive scheduling, the CPU can be taken away from a running process when a scheduling event occurs.
In non-preemptive scheduling, once the CPU is allocated to a process, the process keeps the CPU until it terminates or switches to the waiting state.
The dispatcher is the module that gives control of the CPU to the process selected by the short-term scheduler.
Dispatcher performs three main operations:
The dispatcher saves the state of the currently running process and loads the state of the selected process.
After selecting the process, the dispatcher switches the CPU to user mode so that the selected user process can execute.
The dispatcher transfers control to the correct location in the selected user program so that it can continue execution.
These three dispatcher activities—context switching, switching to user mode, and jumping to the proper location in the user program—are explicitly listed in the supplied material.
Dispatch latency is the time taken by the dispatcher to stop one process and start another process running.
A smaller dispatch latency is desirable because the CPU can start executing the next process more quickly.
This is particularly important in systems requiring fast response.
| CPU Scheduler | Dispatcher |
|---|---|
| Selects the next process to execute. | Gives CPU control to the selected process. |
| Works with the ready queue. | Works after a process has been selected. |
| Decides which process gets the CPU. | Performs the actual transfer of CPU control. |
| Applies the scheduling algorithm. | Performs context switching. |
| Makes the scheduling decision. | Switches to user mode and starts the selected process. |
| Example: selects P2 from P1, P2, P3. | Transfers CPU control to P2. |
Suppose the ready queue contains:
The OS needs to select a process.
The short-term scheduler selects a ready process and allocates the CPU.
If P1 requests I/O or terminates, the scheduler selects another process.
CPU Utilization: Keep the CPU as busy as possible; the material gives a range of 0–100%, with 40–90% stated as typical for a real system.
Throughput: Number of processes completed per unit time.
Turnaround Time: Time from process submission to process completion.
Waiting Time: Time spent waiting in the ready queue.
Response Time: Time from request submission until the first response is produced.
CPU Scheduler: Selects a ready process and allocates the CPU to it.
Dispatcher: Gives control of the CPU to the process selected by the short-term scheduler.
Dispatcher operations: Context switching, switching to user mode and jumping to the proper program location.
Dispatch latency: Time required to stop one process and start another.
0 Comments