Operating System

Concurrent Process and Scheduling

 Process Concept
• A process is a program in execution. Process is not as same as
program code but a lot more than it. A process is an 'active'
entity as opposed to program which is considered to be a
'passive' entity. Attributes held by process include hardware
state, memory, CPU etc.
• To put it in simple terms, we write our computer programs in a
text file and when we execute this program, it becomes a
process which performs all the tasks mentioned in the program.

• When a program is loaded into the memory and it becomes a

process, it can be divided into four sections ─ stack, heap, text
and data.
 Process Section
• Stack:- The process Stack contains the temporary data such as
method/function parameters, return address and local
variables.
• Heap:-This is dynamically allocated memory to a process
during its run time.
• Text section is made up of the compiled program code, read in
from non-volatile storage when the program is launched..
• Data:-This section contains the global and static variables.
Process Section
 Process State
• When a process executes, it passes through different states. These stages
may differ in different operating systems, and the names of these states are
also not standardized.
• In general, a process can have one of the following five states at a time.

• New:- This is the initial state when a process is first started/created.

• Ready:- The process is waiting to be assigned to a processor. Ready

processes are waiting to have the processor allocated to them by the
operating system so that they can run. Process may come into this state
after Start state or while running it by but interrupted by the scheduler to
assign CPU to some other process.
• Running:-Once the process has been assigned to a processor by the OS
scheduler, the process state is set to running and the processor executes its
instructions.
• Waiting
• Process moves into the waiting state if it needs to wait for a
resource, such as waiting for user input, or waiting for a file to
become available.

• Terminated or Exit
• Once the process finishes its execution, or it is terminated by
the operating system, it is moved to the terminated state where
it waits to be removed from main memory.
Diagram of Process State
 Process Control Block (PCB)
A Process Control Block is a data structure maintained by the
Operating System for every process. The PCB is identified by an
integer process ID (PID). A PCB keeps all the information needed to
keep track of a process
Information associated with each process
• Process state:-The current state of the process i.e., whether it is
ready, running, waiting, or whatever.
• Program counter:- Program Counter is a pointer to the address of
the next instruction to be executed for this process.
• CPU registers:- Various CPU registers where process need to be
stored for execution for running state.
• CPU scheduling information:- Process priority and other
scheduling information which is required to schedule the process.
This information includes a process priority,
pointers to scheduling queues, and any other scheduling parameter
 • Memory-management information:-This includes the
information of page table, memory limits, Segment table
depending on memory used by the operating system.

• Accounting information:” -This includes the amount of CPU

used for process execution, time limits, execution ID etc.
This information includes the amount of CPUand real time used, time limits, account numbers, job or process
numbers,and so on
• I/O status information:-This includes a list of I/O devices
allocated to the process. a list of open files, and so on
• The PCB is maintained for a process throughout its lifetime,
and is deleted once the process terminates.
Process Control Block
CPU Switch from Process to Process
 Process Scheduling Queues
• The OS maintains all PCBs in Process Scheduling Queues. The OS
maintains a separate queue for each of the process states and PCBs
of all processes in the same execution state are placed in the same
queue. When the state of a process is changed, its PCB is unlinked
from its current queue and moved to its new state queue.
• The Operating System maintains the following important process
scheduling queues −
• Job queue − This queue keeps all the processes in the system.
• Ready queue − This queue keeps a set of all processes residing in
main memory, ready and waiting to execute. A new process is
always put in this queue.
• Device queues − The processes which are blocked due to
unavailability of an I/O device constitute this queue.
• Schedulers are special system software which handle process
scheduling in various ways. Their main task is to select the
jobs to be submitted into the system and to decide which
process to run. Schedulers are of three types −
• Long-Term Scheduler
• Short-Term Scheduler
• Medium-Term Scheduler
 Long Term Scheduler
• It is also called a job scheduler. A long-term scheduler
determines which programs are admitted to the system for
processing. It selects processes from the queue and loads them
into memory for execution. Process loads into the memory for
CPU scheduling.
• The primary objective of the job scheduler is to provide a
balanced mix of jobs, such as I/O bound and processor bound.
It also controls the degree of multiprogramming. If the degree
of multiprogramming is stable, then the average rate of process
creation must be equal to the average departure rate of
processes leaving the system.
• It is also called as CPU scheduler. Its main objective is to
increase system performance in accordance with the chosen set
of criteria. It is the change of ready state to running state of the
process. CPU scheduler selects a process among the processes
that are ready to execute and allocates CPU to one of them.

• Short-term schedulers, also known as dispatchers, make the

decision of which process to execute next. Short-term
schedulers are faster than long-term schedulers.
• Medium-term scheduling is a part of swapping. It removes the
processes from the memory. It reduces the degree of
multiprogramming. The medium-term scheduler is in-charge
of handling the swapped out-processes.
• A running process may become suspended if it makes an I/O
request. A suspended processes cannot make any progress
towards completion. In this condition, to remove the process
from memory and make space for other processes, the
suspended process is moved to the secondary storage. This
process is called swapping, and the process is said to be
swapped out or rolled out. Swapping may be necessary to
improve the process mix.
Ready Queue vs I/O queue
Representation of Process Scheduling
Action of Medium Term Schedular
 Context Switch
• When CPU switches to another process, the system must save
the state of the old process and load the saved state for the
new process

• Context-switch time is overhead; the system does no useful

work while switching

• Time dependent on hardware support

 Inter Process Communication
• A process can be of two type:
• Independent process.
• Co-operating process.
• An independent process is not affected by the execution of other
processes while a co-operating process can be affected by other
executing processes.
• Though one can think that those processes, which are running
independently, will execute very efficiently but in practical, there are
many situations when co-operative nature can be utilised for
increasing computational speed, convenience and modularity.
• Inter process communication (IPC) is a mechanism which allows
processes to communicate each other and synchronize their actions.
The communication between these processes can be seen as a
method of co-operation between them.
• There are numerous reasons for providing an environment or situation
which allows process co-operation:
• Information sharing: Since a number of users may be interested in the
same piece of information (for example, a shared file), you must provide a
situation for allowing concurrent access to those information.
• Computation speedup: If you want a particular work to run fast, you must
break it into sub-tasks where each of them will get execute in parallel with
the other tasks. Note that such a speed-up can be attained only when the
computer has compound or various processing elements like CPUs or I/O
channels.
• Modularity: You may want to build the system in a modular way by
dividing the system functions into split processes or threads.
• Convenience: Even a single user may work on many tasks at a time. For
example, a user may be editing, formatting, printing, and compiling in
parallel.
• Working together multiple processes, require an inter process
communication (IPC) method which will allow them to
exchange data along with various information. There are two
primary models of inter process communication:
– shared memory and
– message passing.
• In the shared-memory model, a region of memory which is
shared by cooperating processes gets established. Processes
can then able to exchange information by reading and writing
all the data to the shared region. In the message-passing form,
communication takes place by way of messages exchanged
among the cooperating processes.
 Process Synchronization
• Concurrent access to shared data may result in data
inconsistency

• Maintaining data consistency requires mechanisms to ensure

the orderly execution of cooperating processes

• Suppose that we wanted to provide a solution to the consumer-

producer problem that fills all the buffers. We can do so by
having an integer counter that keeps track of the number of full
buffers. Initially, counter is set to 0. It is incremented by the
producer after it produces a new buffer and is decremented by
the consumer after it consumes a buffer.
Producer- Consumer Problem solution
using Counter Variable
Code For Producer Process

while (true) {

/* produce an item and put in nextProduced */

while (counter == BUFFER_SIZE)
; // do nothing
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
 Code for Consumer Process

while (true) {
while (counter == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in nextConsumed
}
 Race Condition
• A race condition is a special condition that may occur inside a
critical section. A critical section is a section of code that is executed
by multiple threads and where the sequence of execution for the
threads makes a difference in the result of the concurrent execution
of the critical section.
• When the result of multiple threads executing a critical section may
differ depending on the sequence in which the threads execute, the
critical section is said to contain a race condition. The term race
condition stems from the metaphor that the threads are racing
through the critical section, and that the result of that race impacts
the result of executing the critical section.
• This may all sound a bit complicated, so I will elaborate more on
race conditions and critical sections in the following sections.
• To prevent race conditions from occurring you must make sure
that the critical section is executed as an atomic instruction.
That means that once a single thread is executing it, no other
threads can execute it until the first thread has left the critical
section.

• Race conditions can be avoided by proper thread

synchronization in critical sections.
 Race Condition
• counter++ could be implemented as
register1 = counter
register1 = register1 + 1
counter = register1

• counter-- could be implemented as

register2 = counter
register2 = register2 – 1
count = register2
Consider this execution interleaving with “counter= 5” initially:
S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute counter = register1 {count = 6 }
S5: consumer execute counter = register2 {count = 4}
 Critical Section
• A critical section is a region of code in which a process uses a
variable (which may be an object or some other data structure)
that is shared with another process (e.g. the “code” that read,
modified, and wrote an account balance in the example you
did.)
• Problems can arise if two processes are in critical sections
accessing the same variable at the same time.
• The critical section problem refers to the problem of how to
ensure that at most one process is executing its critical section
at a given time.
 Solution to Critical-Section Problem
1. Mutual Exclusion - If process Pi is executing in its critical
section, then no other processes can be executing in their
critical sections
2. Progress - If no process is executing in its critical section and
there exist some processes that wish to enter their critical
section, then the selection of the processes that will enter the
critical section next cannot be postponed indefinitely
3. Bounded Waiting - A bound must exist on the number of
times that other processes are allowed to enter their critical
sections after a process has made a request to enter its critical
section and before that request is granted
 Assume that each process executes at a nonzero speed
 No assumption concerning relative speed of the N processes
 Peterson Solution
• Peterson's Solution is a classic software-based solution to the critical
section problem.
• Peterson's solution is based on two processes, P0 and P1, which
alternate between their critical sections and remainder sections. For
convenience of discussion, "this" process is Pi, and the "other"
process is Pj. ( I.e. j = 1 - i )
• Peterson's solution requires two shared data items:
• int turn - Indicates whose turn it is to enter into the critical section.
If turn = = i, then process i is allowed into their critical section.
• boolean flag[ 2 ] - Indicates when a process wants to enter into their
critical section. When process i wants to enter their critical section,
it sets flag[ i ] to true.
Peterson’s Solution for Process i
• In the entry section, process i first raises a flag indicating a desire to
enter the critical section.

• Then turn is set to j to allow the other process to enter their critical
section if process j so desires.

• The while loop is a busy loop ( notice the semicolon at the end ),
which makes process i wait as long as process j has the turn and
wants to enter the critical section.

• Process i lowers the flag[ i ] in the exit section, allowing process j to

continue if it has been waiting.
• To prove that the solution is correct, we must examine the three conditions
listed above:
– Mutual exclusion - If one process is executing their critical section when the other
wishes to do so, the second process will become blocked by the flag of the first
process. If both processes attempt to enter at the same time, the last process to
execute "turn = j" will be blocked.
– Progress - Each process can only be blocked at the while if the other process wants
to use the critical section ( flag[ j ] = = true ), AND it is the other process's turn to
use the critical section ( turn = = j ). If both of those conditions are true, then the
other process ( j ) will be allowed to enter the critical section, and upon exiting the
critical section, will set flag[ j ] to false, releasing process i. The shared variable turn
assures that only one process at a time can be blocked, and the flag variable allows
one process to release the other when exiting their critical section.
– Bounded Waiting - As each process enters their entry section, they set the turn
variable to be the other processes turn. Since no process ever sets it back to their
own turn, this ensures that each process will have to let the other process go first at
most one time before it becomes their turn again.
• Note that the instruction "turn = j" is atomic, that is it is a single machine
instruction which cannot be interrupted.
 Semaphore
• In 1965, Dijkstra proposed a new and very significant technique for
managing concurrent processes by using the value of a simple integer
variable to synchronize the progress of interacting processes. This integer
variable is called semaphore. So it is basically a synchronizing tool and is
accessed only through two low standard atomic operations, wait and signal
designated by P() and V() respectively.
• Two standard operations, wait and signal are defined on the semaphore.
Entry to the critical section is controlled by the wait operation and exit
from a critical region is taken care by signal operation.
• The manipulation of semaphore (S) takes place as following:
• The wait command P(S) decrements the semaphore value by 1..
• The V(S) i.e. signals operation increments the semaphore value by 1.
• Mutual exclusion on the semaphore is enforced within P(S) and V(S). If a
number of processes attempt P(S) simultaneously, only one process will be
allowed to proceed & the other processes will be waiting.
Wait and Signal function
• In practice, semaphores can take on one of two forms:
• Binary semaphores can take on one of two values, 0 or 1. They can
be used to solve the critical section problem as described above, and
are sometimes known as mutexes, because they provide mutual
exclusion.
• Counting semaphores can take on any integer value, and are
usually used to count the number remaining of some limited
resource. The counter is initialized to the number of such resources
available in the system, and whenever the counting semaphore is
greater than zero, then a process can enter a critical section and use
one of the resources. When the counter gets to zero ( or negative in
some implementations ), then the process blocks until another
process frees up a resource and increments the counting semaphore
with a signal call. ( The binary semaphore can be seen as just a
special case where the number of resources initially available is just
one. )
 Semaphore Implementation
• Must guarantee that no two processes can execute wait () and
signal () on the same semaphore at the same time

• Thus, implementation becomes the critical section problem

where the wait and signal code are placed in the crtical section.
– Could now have busy waiting in critical section implementation
• But implementation code is short
• Little busy waiting if critical section rarely occupied

• Note that applications may spend lots of time in critical

sections and therefore this is not a good solution.
 Semaphore Implementation with no Busy waiting

• With each semaphore there is an associated waiting queue.

Each entry in a waiting queue has two data items:
– value (of type integer)
– pointer to next record in the list

• Two operations:
– block – place the process invoking the operation on the
appropriate waiting queue.
– wakeup – remove one of processes in the waiting queue and
place it in the ready queue.
 Semaphore Implementation with no Busy waiting (Cont.)

• Implementation of wait:

wait (S){
value--;
if (value < 0) {
add this process to waiting queue
block(); }
}

• Implementation of signal:

Signal (S){
value++;
if (value <= 0) {
remove a process P from the waiting queue
wakeup(P); }
}
 Deadlock and Starvation
• Deadlock – two or more processes are waiting indefinitely for
an event that can be caused by only one of the waiting
processes
• Let S and Q be two semaphores initialized to 1
P0 P1
wait (S); wait (Q);
wait (Q); wait (S);
. .
. .
. .
signal (S); signal (Q);
signal (Q); signal (S);
• Starvation – indefinite blocking. A process may never be
removed from the semaphore queue in which it is suspended.
Classical Problems of Synchronization

• Bounded-Buffer Problem
• Readers and Writers Problem
• Dining-Philosophers Problem
 Bounded-Buffer Problem
• This is a generalization of the producer-consumer problem
wherein access is controlled to a shared group of buffers of a
limited size. In this solution, the two counting semaphores
"full" and "empty" keep track of the current number of full and
empty buffers respectively ( and initialized to 0 and N
respectively. )
• The binary semaphore mutex controls access to the critical
section.
• The producer and consumer processes are nearly identical -
One can think of the producer as producing full buffers, and
the consumer producing empty buffers Semaphore mutex
initialized to the value 1
• Semaphore full initialized to the value 0
• Semaphore empty initialized to the value N.
Bounded Buffer Problem (Cont.)
Bounded Buffer Problem (Cont.)
 Readers-Writers Problem
• In the readers-writers problem there are some processes ( termed readers ) who only
read the shared data, and never change it, and there are other processes ( termed
writers ) who may change the data in addition to or instead of reading it. There is no
limit to how many readers can access the data simultaneously, but when a writer
accesses the data, it needs exclusive access.
• There are several variations to the readers-writers problem, most centered around
relative priorities of readers versus writers. The first readers-writers problem gives
priority to readers. In this problem, if a reader wants access to the data, and there is
not already a writer accessing it, then access is granted to the reader. A solution to
this problem can lead to starvation of the writers, as there could always be more
readers coming along to access the data. ( A steady stream of readers will jump
ahead of waiting writers as long as there is currently already another reader
accessing the data, because the writer is forced to wait until the data is idle, which
may never happen if there are enough readers. )
• The second readers-writers problem gives priority to the writers. In this problem,
when a writer wants access to the data it jumps to the head of the queue - All
waiting readers are blocked, and the writer gets access to the data as soon as it
becomes available. In this solution the readers may be starved by a steady stream of
writers.
 Readers-Writers Problem (Cont.)
• The following code is an example of the first readers-writers
problem, and involves an important counter and two binary
semaphores: readcount is used by the reader processes, to count the
number of readers currently accessing the data.
• mutex is a semaphore used only by the readers for controlled access
to readcount.
• rw_mutex is a semaphore used to block and release the writers. The
first reader to access the data will set this lock and the last reader to
exit will release it; The remaining readers do not touch rw_mutex. (
Eighth edition called this variable wrt. )
• Note that the first reader to come along will block on rw_mutex if
there is currently a writer accessing the data, and that all following
readers will only block on mutex for their turn to increment
readcount.
Readers-Writers Problem (Cont.)
 Dining-Philosophers Problem
• The dining philosophers problem is a classic synchronization
problem involving the allocation of limited resources amongst a
group of processes in a deadlock-free and starvation-free manner:
Consider five philosophers sitting around a table, in which there are
five chopsticks evenly distributed and an endless bowl of rice in the
center, as shown in the diagram below. ( There is exactly one
chopstick between each pair of dining philosophers. )
• These philosophers spend their lives alternating between two
activities: eating and thinking.
• When it is time for a philosopher to eat, it must first acquire two
chopsticks - one from their left and one from their right.
• When a philosopher thinks, it puts down both chopsticks in their
original locations.
 Dining-Philosophers Problem (Cont.)

• One possible solution, as shown in the following code section,

is to use a set of five semaphores ( chopsticks[ 5 ] ), and to
have each hungry philosopher first wait on their left chopstick
( chopsticks[ i ] ), and then wait on their right chopstick (
chopsticks[ ( i + 1 ) % 5 ] )
• But suppose that all five philosophers get hungry at the same
time, and each starts by picking up their left chopstick. They
then look for their right chopstick, but because it is
unavailable, they wait for it, forever, and eventually all the
philosophers starve due to the resulting deadlock.
• Some potential solutions to the problem include: Only allow
four philosophers to dine at the same time. ( Limited
simultaneous processes. )
• Allow philosophers to pick up chopsticks only when both are
available, in a critical section. ( All or nothing allocation of
critical resources. )
• Use an asymmetric solution, in which odd philosophers pick
up their left chopstick first and even philosophers pick up their
right chopstick first. ( Will this solution always work? What if
there are an even number of philosophers? )
 CPU Scheduling
• CPU scheduling is a process which allows one process to use
the CPU while the execution of another process is on hold(in
waiting state) due to unavailability of any resource like I/O etc,
thereby making full use of CPU. The aim of CPU scheduling
is to make the system efficient, fast and fair.
• Whenever the CPU becomes idle, the operating system must
select one of the processes in the ready queue to be executed.
The selection process is carried out by the short-term scheduler
(or CPU scheduler). The scheduler selects from among the
processes in memory that are ready to execute, and allocates
the CPU to one of them.
 CPU-I/O Burst Cycle

• Almost all processes alternate between two states in a

continuing cycle, as shown in Figure 5.1 below :
– A CPU burst of performing calculations, and
– An I/O burst, waiting for data transfer in or out of the system.
• Whenever the CPU becomes idle, it is the job of the CPU
Scheduler ( a.k.a. the short-term scheduler ) to select another
process from the ready queue to run next. The storage structure
for the ready queue and the algorithm used to select the next
process are not necessarily a FIFO queue. There are several
alternatives to choose from, as well as numerous adjustable
parameters for each algorithm
• CPU scheduling decisions take place under one of four conditions:
– When a process switches from the running state to the waiting state,
such as for an I/O request or invocation of the wait( ) system call.
– When a process switches from the running state to the ready state, for
example in response to an interrupt.
– When a process switches from the waiting state to the ready state, say
at completion of I/O or a return from wait( ).
– When a process terminates.
• For conditions 1 and 4 there is no choice - A new process must be
selected. For conditions 2 and 3 there is a choice - To either continue
running the current process, or select a different one. If scheduling
takes place only under conditions 1 and 4, the system is said to be
non-preemptive. Under these conditions, once a process starts
running it keeps running, until it either voluntarily blocks or until it
finishes. Otherwise the system is said to be preemptive.
• Dispatcher
• The dispatcher is the module that gives control of the CPU to
the process selected by the scheduler. This function involves:
– Switching context.
– Switching to user mode.
– Jumping to the proper location in the newly loaded program.
• The dispatcher needs to be as fast as possible, as it is run on
every context switch. The time consumed by the dispatcher is
known as dispatch latency.
 Scheduling Criteria

• There are several different criteria to consider when trying to select

the "best" scheduling algorithm for a particular situation and
environment, including:
– CPU utilization - Ideally the CPU would be busy 100% of the time, so
as to waste 0 CPU cycles. On a real system CPU usage should range
from 40% ( lightly loaded ) to 90% ( heavily loaded. )
– Throughput - Number of processes completed per unit time. May
range from 10 / second to 1 / hour depending on the specific processes.
– Turnaround time - Time required for a particular process to complete,
from submission time to completion.
– Waiting time - How much time processes spend in the ready queue
waiting their turn to get on the CPU.
– Response time - The time taken in an interactive program from the
issuance of a command to the commence of a response to that
command.
This measure, called response time, is the time it takes to start responding, not the time it takes
to output the response
 Scheduling Algorithms

• First Come First Serve (FCFS)

• Shortest Job First Scheduling Algorithm (SJF)
• Priority Scheduling
• Round Robin Scheduling
• Multilevel Queue Scheduling
• Multilevel Feedback Queue Scheduling Algorithm
 First Come First Serve
• FCFS is very simple - Just a FIFO queue, like customers
waiting in line at the bank or the post office or at a copying
machine.
• Unfortunately, however, FCFS can yield some very long
average wait times, particularly if the first process to get there
takes a long time. For example, consider the following three
processes:
Process Burst Time

P1 24

P2 3

P3 3
• In the first Gantt chart below, process P1 arrives first. The
average waiting time for the three processes is ( 0 + 24 + 27 ) /
3 = 17.0 ms.
• In the second Gantt chart below, the same three processes have
an average wait time of ( 0 + 3 + 6 ) / 3 = 3.0 ms. The total run
time for the three bursts is the same, but in the second case two
of the three finish much quicker, and the other process is only
delayed by a short amount.
• FCFS can also block the system in a busy dynamic system in
another way, known as the convoy effect. When one CPU
intensive process blocks the CPU, a number of I/O intensive
processes can get backed up behind it, leaving the I/O devices
idle. When the CPU hog finally relinquishes the CPU, then the
I/O processes pass through the CPU quickly, leaving the CPU
idle while everyone queues up for I/O, and then the cycle
repeats itself when the CPU intensive process gets back to the
ready queue.
 Shortest-Job-First Scheduling, SJF

• The idea behind the SJF algorithm is to pick the quickest

fastest little job that needs to be done, get it out of the way
first, and then pick the next smallest fastest job to do next.
• ( Technically this algorithm picks a process based on the next
shortest CPU burst, not the overall process time. )
• For example, the Gantt chart below is based upon the
following CPU burst times, ( and the assumption that all jobs
arrive at the same time. )
Process Burst Time
P1 6
P2 8
P3 7
P4 3
• In the case above the average wait time is ( 0 + 3 + 9 + 16 ) / 4
= 7.0 ms, ( as opposed to 10.25 ms for FCFS for the same
processes. )
• SJF can be proven to be the fastest scheduling algorithm, but it
suffers from one important problem: How do you know how
long the next CPU burst is going to be? For long-term batch
jobs this can be done based upon the limits that users set for
their jobs when they submit them, which encourages them to
set low limits, but risks their having to re-submit the job if they
set the limit too low. However that does not work for short-
term CPU scheduling on an interactive system.
• Another option would be to statistically measure the run time
characteristics of jobs, particularly if the same tasks are run
repeatedly and predictably. But once again that really isn't a
viable option for short term CPU scheduling in the real world.
• A more practical approach is to predict the length of the next burst,
based on some historical measurement of recent burst times for this
process. One simple, fast, and relatively accurate method is the
exponential average, which can be defined as follows. ( The book
uses tau and t for their variables, but those are hard to distinguish
from one another and don't work well in HTML. )
• estimate[ i + 1 ] = alpha * burst[ i ] + ( 1.0 - alpha ) * estimate[ i ]
• In this scheme the previous estimate contains the history of all
previous times, and alpha serves as a weighting factor for the
relative importance of recent data versus past history. If alpha is 1.0,
then past history is ignored, and we assume the next burst will be the
same length as the last burst. If alpha is 0.0, then all measured burst
times are ignored, and we just assume a constant burst time. Most
commonly alpha is set at 0.5, as illustrated in Figure 5.3:
• SJF can be either preemptive or non-preemptive. Preemption
occurs when a new process arrives in the ready queue that has
a predicted burst time shorter than the time remaining in the
process whose burst is currently on the CPU. Preemptive SJF
is sometimes referred to as shortest remaining time first
scheduling.
• For example, the following Gantt chart is based upon the
following data:
Process Arrival Time Burst Time
P1 0 8
P2 1 4
P3 2 9
p4 3 5
• The average wait time in this case is ( ( 5 - 3 ) + ( 10 - 1 ) + (
17 - 2 ) ) / 4 = 26 / 4 = 6.5 ms. ( As opposed to 7.75 ms for
non-preemptive SJF or 8.75 for FCFS. )
 Priority Scheduling

• Priority scheduling is a more general case of SJF, in which

each job is assigned a priority and the job with the highest
priority gets scheduled first. ( SJF uses the inverse of the next
expected burst time as its priority - The smaller the expected
burst, the higher the priority. )
• Note that in practice, priorities are implemented using integers
within a fixed range, but there is no agreed-upon convention as
to whether "high" priorities use large numbers or small
numbers. This book uses low number for high priorities, with
0 being the highest possible priority.
• For example, the following Gantt chart is based upon these
process burst times and priorities, and yields an average
waiting time of 8.2 ms:
Process Burst Time Priority
P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2
• Priorities can be assigned either internally or externally. Internal priorities
are assigned by the OS using criteria such as average burst time, ratio of
CPU to I/O activity, system resource use, and other factors available to the
kernel. External priorities are assigned by users, based on the importance of
the job, fees paid, politics, etc.
• Priority scheduling can be either preemptive or non-preemptive.
• Priority scheduling can suffer from a major problem known as indefinite
blocking, or starvation, in which a low-priority task can wait forever
because there are always some other jobs around that have higher priority.
– If this problem is allowed to occur, then processes will either run
eventually when the system load lightens ( at say 2:00 a.m. ), or will
eventually get lost when the system is shut down or crashes. ( There are
rumors of jobs that have been stuck for years. )
– One common solution to this problem is aging, in which priorities of jobs
increase the longer they wait. Under this scheme a low-priority job will
eventually get its priority raised high enough that it gets run.
 Round Robin Scheduling

• Round robin scheduling is similar to FCFS scheduling, except that

CPU bursts are assigned with limits called time quantum.
• When a process is given the CPU, a timer is set for whatever value
has been set for a time quantum.
– If the process finishes its burst before the time quantum timer expires,
then it is swapped out of the CPU just like the normal FCFS algorithm.
– If the timer goes off first, then the process is swapped out of the CPU
and moved to the back end of the ready queue.
• The ready queue is maintained as a circular queue, so when all
processes have had a turn, then the scheduler gives the first process
another turn, and so on.
• RR scheduling can give the effect of all processors sharing the CPU
equally, although the average wait time can be longer than with
other scheduling algorithms. In the following example the average
wait time is 5.66 ms.
Process Burst Time
P1 24
P2 3
P3 3
• The performance of RR is sensitive to the time quantum
selected. If the quantum is large enough, then RR reduces to
the FCFS algorithm; If it is very small, then each process gets
1/nth of the processor time and share the CPU equally.
• BUT, a real system invokes overhead for every context switch,
and the smaller the time quantum the more context switches
there are. ( See Figure 6.4 below. ) Most modern systems use
time quantum between 10 and 100 milliseconds, and context
switch times on the order of 10 microseconds, so the overhead
is small relative to the time quantum.
• Turn around time also varies with quantum time, in a non-
apparent manner. Consider, for example the processes shown
in Figure 6.5:
• In general, turnaround time is minimized if most processes
finish their next cpu burst within one time quantum. For
example, with three processes of 10 ms bursts each, the
average turnaround time for 1 ms quantum is 29, and for 10
ms quantum it reduces to 20. However, if it is made too large,
then RR just degenerates to FCFS. A rule of thumb is that 80%
of CPU bursts should be smaller than the time quantum.
 Multilevel Queue Scheduling

• When processes can be readily categorized, then multiple

separate queues can be established, each implementing
whatever scheduling algorithm is most appropriate for that
type of job, and/or with different parametric adjustments.
• Scheduling must also be done between queues, that is
scheduling one queue to get time relative to other queues. Two
common options are strict priority ( no job in a lower priority
queue runs until all higher priority queues are empty ) and
round-robin ( each queue gets a time slice in turn, possibly of
different sizes. )
• Note that under this algorithm jobs cannot switch from queue
to queue - Once they are assigned a queue, that is their queue
until they finish.
 Multilevel Feedback-Queue Scheduling

• Multilevel feedback queue scheduling is similar to the ordinary multilevel

queue scheduling described above, except jobs may be moved from one
queue to another for a variety of reasons:
– If the characteristics of a job change between CPU-intensive and I/O
intensive, then it may be appropriate to switch a job from one queue to
another.
– Aging can also be incorporated, so that a job that has waited for a long time
can get bumped up into a higher priority queue for a while.
• Multilevel feedback queue scheduling is the most flexible, because it can
be tuned for any situation. But it is also the most complex to implement
because of all the adjustable parameters. Some of the parameters which
define one of these systems include:
– The number of queues.
– The scheduling algorithm for each queue.
– The methods used to upgrade or demote processes from one queue to
another. ( Which may be different. )
– The method used to determine which queue a process enters initially.
• Now let us suppose that queue 1 and 2 follow round robin with
time quantum 4 and 8 respectively and queue 3 follow FCFS.
One implementation of MFQS is given below –
• When a process starts executing then it first enters queue 1.
• In queue 1 process executes for 4 unit and if it completes in
this 4 unit or it gives CPU for I/O operation in this 4 unit than
the priority of this process does not change and if it again
comes in the ready queue than it again starts its execution in
Queue 1.
• If a process in queue 1 does not complete in 4 unit then its
priority gets reduced and it shifted to queue 2
• Above points 2 and 3 are also true for queue 2 processes but
the time quantum is 8 unit.In a general case if a process does
not complete in a time quantum than it is shifted to the lower
priority queue.
• In the last queue, processes are scheduled in FCFS manner.
• A process in lower priority queue can only execute only when
higher priority queues are empty.
• A process running in the lower priority queue is interrupted by
a process arriving in the higher priority queue.
 A CONTROL STRUCTURE FOR
INDICATING PARALLELISM
• Many programmmg language constructs for indicating parallelism have
appeared in the literature. These generally involve pairs of statements as
follows
• One statement indicating that execution is to split into several parallel
execution sequences (threads of control).
• One statement indicating that certain parallel execution sequences are to
merge sequential execution is to resume
• These statements occur in pairs and are commonly called parbegin for
begin end parallel begin and end paren in text use parbegin/parend as
concurrent execution Fig. 4.1 suggested by Dijkstra form is shown par
begin statement statement 2 statement parend The parbeginparend
parallelism construct. a program currently executing a sin parbegin
construct. This causes threads of control-one for each state simple
statements, procedure calls, b or combinations of these. Each and reaches
the parend. Wh a single thread of control is after the parend.
 Multiple-Processor Scheduling

• When multiple processors are available, then the scheduling

gets more complicated, because now there is more than one
CPU which must be kept busy and in effective use at all times.
• Load sharing revolves around balancing the load between
multiple processors.
• Multi-processor systems may be heterogeneous, ( different
kinds of CPUs ), or homogenous, ( all the same kind of CPU
).
• Issue may be related to
– which process to be run and on which CPU
– Whether process are unrelated or come into group.
Approaches to Multiple-Processor Scheduling

• One approach to multi-processor scheduling is asymmetric

multiprocessing, in which one processor is the master,
controlling all activities and running all kernel code, while the
other runs only user code. This approach is relatively simple,
as there is no need to share critical system data.

• Another approach is symmetric multiprocessing, SMP, where

each processor schedules its own jobs, either from a common
ready queue or from separate ready queues for each processor.
 Multi processor timesharing
• The simplest strategy of scheduling is that of time sharing by
maintaining a global ready queue as they would be in
uniprocessor system. it can never happen would be in a
processor system. It provides automatic load balancing
because it can never happen one CPU is idle while other are
overloaded.
• The disadvantages of this approach overhead in contention for
the scheduling data structure as the numbers of CPUs grow
and the usual overhead in doing a context switch when a
process blocks for I/O.
 Load Balancing

• Obviously an important goal in a multiprocessor system is to

balance the load between processors, so that one processor won't be
sitting idle while another is overloaded.
• Systems using a common ready queue are naturally self-balancing,
and do not need any special handling. Most systems, however,
maintain separate ready queues for each processor.
• Balancing can be achieved through either push migration or pull
migration:
– Push migration involves a separate process that runs periodically, ( e.g.
every 200 milliseconds ), and moves processes from heavily loaded
processors onto less loaded ones.
– Pull migration involves idle processors taking processes from the
ready queues of other processors.
 Affinity Scheduling
• Processor Affinity means a processes has an affinity for the
processor on which it is currently running.
• When a process runs on a specific processor there are certain effects
on the cache memory. The data most recently accessed by the
process populate the cache for the processor and as a result
successive memory access by the process are often satisfied in the
cache memory. Now if the process migrates to another processor, the
contents of the cache memory must be invalidated for the first
processor and the cache for the second processor must be
repopulated. Because of the high cost of invalidating and
repopulating caches, most of the SMP(symmetric multiprocessing)
systems try to avoid migration of processes from one processor to
another and try to keep a process running on the same processor.
This is known as PROCESSOR AFFINITY.