MODULE - 2

Process
Management
 Process Management

● An operating system executes a variety of programs:

• Batch system – jobs
• Time-shared systems – user programs or tasks
● Process – a program in execution; process execution must progress in sequential fashion
● Program is passive entity stored on disk (executable file), process is active entity

• Program becomes process when executable file loaded into memory

● Execution of program c a n started via GUI mouse clicks, command line entry of its name,
etc
● One program can be several processes.
● One process will be executed as thread.
Thread: It is the unit of execution within a process. A process can have just one thread to many
threads
 Multiple parts of Process
 Multiple parts
 The program code, also called text section
 Current activity including program
counter, processor registers
 Stack containing temporary data
Function parameters, return addresses,
local variables
 Data section containing global variables
 Heap containing memory dynamically
allocated during run time
Process in
Memory
 Process State
 As a process executes, it changes
state
 new: The process is being
created
 running: Instructions are being
executed
 waiting: The process is waiting
for some event to occur
 ready: The process is waiting to be assigned to a processor
 terminated: The process has finished execution
 Suspend Ready
 Suspend wait
 Process Control Block (PCB)
Information associated with each process (also called
task control block)
 Process state – running, waiting, etc
 Program counter – location of instruction to next execute
 CPU registers – contents of all process-centric registers
 CPU scheduling information- priorities, scheduling queue
pointers
 Memory-management information – memory allocated to
the process
 Accounting information – CPU used, clock time elapsed
since start, time limits
 I/O status information – I/O devices allocated to process,
list of open files
CPU Switch From Process to Process
 Process Scheduling

 Objective of Computer system is to Maximize CPU use, quickly switch processes

onto CPU for time sharing
 Process scheduler selects among available processes for next execution on CPU
 Process scheduler maintains scheduling queues of processes
 Job queue – set of all processes in the system
 Ready queue – set of all processes residing in main memory, ready and waiting
to execute
 Device queues – set of processes waiting for an I/O device
 Processes migrate among the various queues
Ready Queue And Various I/O Device Queues
● Queueing diagram represents queues, resources, flows

Representation of Process Scheduling

 Schedulers

 Process – migrates among various queues

 OS must select processes form these queues in some fashion
 The selection process is carried out by the appropriate scheduler
 Short-term scheduler (or CPU scheduler) – selects which process should be
executed next and allocates CPU
 Sometimes the only scheduler in a system
 Short-term scheduler is invoked frequently (milliseconds)  (must be fast)
 Long-term scheduler (or job scheduler) – selects which processes should be
brought into the ready queue
 Long-term scheduler is invoked infrequently (seconds, minutes)  (may be slow)
 The long-term scheduler controls the degree of multiprogramming
 Long term scheduler should make a careful selection
 Processes can be described as either:
 I/O-bound process – spends more time doing I/O than computations,
many short CPU bursts
 CPU-bound process – spends more time doing computations; few very long CPU
bursts
 Long-term scheduler strives for good process mix

 In some systems long term scheduler may be absent

 Example- time sharing systems like UNIX and Microsoft Windows
 Medium-term scheduler can be added if degree of multiple programming
needs to decrease
 Remove process from memory, store on disk, bring back in from disk to
continue execution: swapping
Medium-term
scheduler
 Context switch
 When CPU switches to another process, the system must save the state of the old
process and load the saved state ( state restore) for the new process via a context
switch
 Context of a process represented in the PCB
 Context-switch time is overhead; the system does no useful work while switching
 The more complex the OS and the PCB  the longer the context switch
 Time dependents on the memory speed, the number of registers that must be copied and
the existence of special instructions
 Also dependent on hardware support
 Some hardware provides multiple sets of registers per CPU  context switch simply
requires changing the pointer to the current register set
 Process Creation
 Parent process create children processes, which, in turn create other processes,
forming a tree of processes
 Generally, process identified and managed via a process identifier (pid)

 Resource sharing options

 Parent and children share all resources
 Children share subset of parent’s resources
 Parent and child share no resources
 Execution options
 Parent and children execute concurrently
 Parent waits until children terminate
A Tree of Processes in Linux
init
pid = 1

login kthreadd sshd

pid = 8415 pid = 2 pid = 3028

bash khelper pdflush sshd

pid = 8416 pid = 6 pid = 200 pid = 3610

emacs tcsch
ps
pid = 9204 pid = 4005
pid = 9298
 Address space
 Child duplicate of parent
 Child has a program loaded into it
 UNIX examples
 fork() system call creates new process
 exec() system call used after a fork() to replace the process’
memory space with a new program
C Program Forking Separate Process
Creating a Separate Process via Windows API
 Process Termination

 Process executes last statement and then asks the operating system to delete it
using the exit() system call.
 Returns status data from child to parent (via wait())
 Process’ resources are deallocated by operating system
 Parent may terminate the execution of children processes using the abort() system
call. Some reasons for doing so:
 Child has exceeded allocated resources
 Task assigned to child is no longer required
 The parent is exiting and the operating systems does not allow a child to
continue if its parent terminates
 Some operating systems do not allow child to exists if its parent has terminated. If a
process terminates, then all its children must also be terminated.
 cascading termination. All children, grandchildren, etc. are
terminated.
 The termination is initiated by the operating system.
 The parent process may wait for termination of a child process by using the wait()
system call. The call returns status information and the pid of the terminated process
pid = wait(&status);
 If no parent waiting (did not invoke wait()) process is a zombie
 If parent terminated without invoking wait , process is an orphan
Interprocess Communication
 Processes within a system may be independent or cooperating
 Independent - if it cannot affect or be affected by the other processes executing
in the system – do not share data with any
 Cooperating process can affect or be affected by other processes, including sharing data
 Reasons for cooperating processes:
 Information sharing
 Computation speedup
 Modularity
 Convenience
 Cooperating processes need interprocess communication (IPC) to exchange the data and
information between each other.
 Two models of IPC : 1) Shared memory 2) Message passing
 Communication Models
(a) Message passing. (b) shared memory.

 Message passing is good for

exchanging smaller amount of
data
 Easier to implement
 Shared memory allows
maximum speed
 Faster than message passing
because message passing
requires system calls
 Interprocess Communication – Shared
Memory
 An area of memory shared among the processes that wish to communicate
 A shared-memory region resides in the address space of the process creating the
shared-memory segment

 The other process must attach it to their address space

 The communication is under the control of the users processes not the operating system.
 Major issues is to provide mechanism that will allow the user processes to
synchronize their actions when they access shared memory.

 Synchronization is discussed in great details in Chapter 5.

 Producer-Consumer Problem
 Example for cooperating processes

 Producer process produces information that is consumed by a consumer process

 Example : a compiler may produce assembly code which is consumed by an Assembler, in
turn assembler produces the object modules which are consumed by loaders
 One solution to this is shared memory
 To allow producer and consumer to run concurrently we must have available a buffer that can
be filled by producer and emptied by consumer
 A producer will produce one item while the consumer is consuming another item
 Synchronization is important

 Two types of buffer can be used

 unbounded-buffer places no practical limit on the size of the buffer
 bounded-buffer assumes that there is a fixed buffer size
 Bounded-Buffer – Shared-Memory Solution
 Shared data
#define BUFFER_SIZE 10
typedef struct {
...
} item;

item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;

 Solution is correct, but can only use BUFFER_SIZE-1 elements

 If in == out buffer is empty
 If ((in+1)%BUFFER_SIZE) == out buffer is full
Bounded-Buffer – Producer

item next _produced ; item

while (true) { next_consumed;
/* produce an item in next produced */ while (true) {
while (((in + 1) % BUFFER_SIZE) == out) while (in == out)

; /* do nothing */ ; /* do nothing */
next_consumed = buffer[out];
buffer[in] = next_produced;
out = (out + 1) % BUFFER_SIZE;
in = (in + 1) % BUFFER_SIZE;
}
/* consume the item in next consumed */
}
 Interprocess Communication – Message
Passing
 Mechanism for processes to communicate and to synchronize their actions without sharing
the address space
 Useful for distributed systems where processes reside on different systems
 IPC facility provides two operations:
 send(message)
 receive(message)
 The message size is either fixed or variable
 Fixed size easy to implement, programming becomes difficult
 Variable size difficult to implement, easy for programming
 If processes P and Q wish to communicate, they need to:
 Establish a communication link between them
 Exchange messages via send/receive
 Implementation of communication link
 Physical:
Shared memory

Hardware bus

Network

 Logical:
 Direct or indirect
 Synchronous or asynchronous
 Automatic or explicit buffering

 Implementation issues with :

 Naming
 Synchronization
 Buffering
 Naming
Direct Communication
 Processes must name each other explicitly:
 send (P, message) – send a message to process P
 receive(Q, message) – receive a message from process Q
 Properties of communication link
 Links are established automatically
 A link is associated with exactly one pair of communicating processes
 Between each pair there exists exactly one link
 The link may be unidirectional, but is usually bi-directional
 This scheme is symmetry in addressing means both sender and receiver must name each other
 Asymmetry in addressing, here only sender names the recipient
 send (P, message) – send a message to process P
 receive ( id, message) – receive a message from any process; the id is set to the name of the
process with which communication has taken place
Indirect Communication
 Messages are directed and received from mailboxes (also referred to as ports)
 Each mailbox has a unique id
 Processes can communicate only if they share a mailbox
 Properties of communication link
 Link established only if processes share a common mailbox
 A link may be associated with many processes
 Each pair of processes may share several communication links
 Link may be unidirectional or bi-directional
 Operations
 create a new mailbox (port)
 send and receive messages through mailbox
 destroy a mailbox
 Primitives are defined as:
send(A, message) – send a message to mailbox A
receive(A, message) – receive a message from mailbox A
 Mailbox sharing
 P1, P2, and P3 share mailbox A
 P1, sends; P2 and P3 receive
 Who gets the message?
 Solutions
 Allow a link to be associated with at most two processes
 Allow only one process at a time to execute a receive operation
 Allow the system to select arbitrarily the receiver. Sender is notified who the
receiver was.
 Mailbox may be owned by a process or by OS
 If mailbox is owned by a process, we can distinguish between the owner ( only receive
messages) and the user ( who can only send the messages)
 Owned by OS, mailbox is independent and is not attached to any particular process

 OS must allow a process to do the following

 Create a mailbox
 Send and receive messages through the mailbox
 Delete the mailbox
 Synchronization
 Message passing may be either blocking or non-blocking
 Blocking is considered synchronous
 Blocking send -- the sender is blocked until the message is received
 Blocking receive -- the receiver is blocked until a message is available
 Non-blocking is considered asynchronous
 Non-blocking send -- the sender sends the message and continue
 Non-blocking receive -- the receiver receives:
 A valid message, or
 Null message
 Different combinations possible
 If both send and receive are blocking, we have a rendezvous
 Buffering
 Queue of messages attached to the link.
 implemented in one of three ways
1. Zero capacity – no messages are queued on a link. Sender must wait for receiver
(rendezvous)
2. Bounded capacity – finite length of n messages. Sender must wait if link full
3. Unbounded capacity – infinite length. Sender never waits
Multithreaded Programming
Module 2

Overview,Multithreading Models,
Thread Libraries,Threading Issues
 Overview
● A thread is a basic unit of CPU utilization, consisting of a program
counter, a stack, and a set of registers, ( and a thread ID. )
● Traditional (heavyweight) processes have a single thread of control - There
is one program counter, and one sequence of instructions that can be carried
out at any given time.
● As shown in Figure 4.1, multi-threaded applications have multiple threads
within a single process, each having their own program counter, stack and
set of registers, but sharing common code, data, and certain structures such as
open files.
 Motivation
● Threads are very useful in modern programming whenever a process has multiple
tasks to perform independently of the others.
● This is particularly true when one of the tasks may block, and it is desired to allow
the other tasks to proceed without blocking.
● For example in a word processor, a background thread may check spelling and
grammar while a foreground thread processes user input ( keystrokes ), while yet a
third thread loads images from the hard drive, and a fourth does periodic automatic
backups of the file being edited.
● Another example is a web server - Multiple threads allow for multiple requests to be
satisfied simultaneously, without having to service requests sequentially or to fork off
separate processes for every incoming request.
 Benefits
There are four major categories of benefits to multi-threading:
● Responsiveness - One thread may provide rapid response while other threads are
blocked or slowed down doing intensive calculations.
● Resource sharing - By default, threads share common code, data, and other
resources, which allows multiple tasks to be performed simultaneously in a single
address space.
● Economy - Creating and managing threads (and context switches between them )
is much faster
● Scalability i.e. Utilization of multiprocessor architectures - A single
threaded process can only run on one CPU, whereas the execution of a multi-
threaded application may be split amongst available processors.
 Multithreading Models

● There are two types of threads to be managed in a modern system: User

threads and kernel threads.
● User threads are supported above the kernel, without kernel support. These
are the threads that application programmers would put into their programs.
● Kernel threads are supported within the kernel of the OS itself. All modern
OSes support kernel level threads, allowing the kernel to perform multiple
simultaneous tasks and/or to service multiple kernel system calls
simultaneously.
● In a specific implementation, the user threads must be mapped to kernel
threads, using one of the following strategies.
 Many-to- one Model
● In the many-to-one model, many user-level threads are all mapped onto a
single kernel thread.
● Thread management is handled by the thread library in user space, which is very
efficient.
● However, if a blocking system call is made, then the entire process blocks,
even if the other user threads would be able to continue.
● Because a single kernel thread can operate only on a single CPU, the many-
to-one model does not allow individual processes to be split across multiple
CPUs.
● Green threads for Solaris and GNU Portable Threads implement the many-
to-one model in the past, but few systems continue to do so today.
 One-to-One Model
● The one-to-one model creates a separate kernel thread to handle each
user thread.
● One-to-one model overcomes the problems of blocking system calls and
the splitting of processes across multiple CPUs.
● However the overhead of managing the one-to-one model is more
significant, involving more overhead and slowing down the system.
● Most implementations of this model place a limit on how many threads
can be created.
● Linux and Windows from 95 to XP implement the one-to-one model for
threads.
 Many-to-Many Model

● The many-to-many model multiplexes any number of user threads

onto an equal or smaller number of kernel threads, combining the
best features of the one-to-one and many-to-one models.
● Users have no restrictions on the number of threads created.
● Blocking kernel system calls do not block the entire process.
● One popular variation of the many-to-many model is the two-tier model, which
allows either many-to-many or one-to-one operation.
● IRIX, HP-UX, and Tru64 UNIX use the two-tier model, as did Solaris prior to
Solaris 9.
 Thread Libraries

● Thread libraries provide programmers with an API for creating and managing
threads.
● Thread libraries may be implemented either in user space or in kernel space. The
former involves API functions implemented solely within user space, with no kernel
support. The latter involves system calls, and requires a kernel with thread library
support.
● There are three main thread libraries in use today:
1. POSIX Pthreads - may be provided as either a user or kernel library, as an
extension to the POSIX standard.
2. Win32 threads - provided as a kernel-level library on Windows systems.
3. Java threads - Since Java generally runs on a Java Virtual Machine (JVM) ,
the implementation of threads is based upon whatever OS and hardware the
JVM is running on, i.e. either Pthreads or Win32 threads depending on the
system.
 Pthreads

● The POSIX standard (IEEE 1003.1c) defines the specification for pThreads,
not implementation

● pThreads are available on Solaris, Linux, Mac OSX, Tru64, and via public
domain shareware for Windows.

● Global variables are shared amongst all threads.

● One thread can wait for the others to rejoin before continuing

● pThreads begin execution in a specified function, for example the runner( )

function:
 Win32 Threads

● The Win32 threads are implemented in the kernel space of Windows OS

● The multi-threaded applications can use the Win32 API library similar to
Pthread library.

● We must include Windows.h header file while using win32 API.

 Java Threads
● Threads are the fundamental model of program execution in a java program
● Java language and its API provides a rich set of features for the creation and
management of threads
● All java program comprises at least a single thread of control
● There are two techniques for creating threads
● One approach is to create a new class that is derived from the Thread class
and to override its run( ) method
● Alternate approach is to define a class that implements the Runnable
interface
Continued

● The Runnable interface is defined as follows:

public interface Runnable
{
public abstract void run();
}

● When a class implements Runnable, it must define a run() method

● The code implementing the run( ) method runs a separate thread
 Threading Issues

These are the issues to be consider in multithreaded programs

● Semantics of fork() and exec() system calls
● Thread cancellation
● Signal handling
● Thread pools
● Thread specific data
● Scheduler activations
 The fork ( ) and exec( ) system calls

Q: If one thread forks, is the entire process copied, or is the new process
single-threaded?
A: System dependant.
A: If the new process execs right away, there is no need to copy all the other
threads. If it doesn't, then the entire process should be copied.
A: Many versions of UNIX provide multiple versions of the fork call for this
purpose.
Continued

● UNIX systems supports two versions of fork(), one that duplicates all
threads and another that duplicates only the thread that invoked the fork()
system call.

● exec() : program specified in parameter to exec() will replace the memory

of the process with specific new program to be executed.

● When we invoke exec() immediately after fork(), duplication becomes

unnecessary.
 Cancellation

● The task of terminating a thread before it has completed is called thread

cancellation.
● Thread chosen to be terminated is referred to target thread.
● There are 2 forms of thread cancellation
1. Asynchronous cancellation
● One thread immediately terminates the target thread.
● A problem with this type of cancellation arise when a target thread have been
allotted resources and it is in midst of updating data it is sharing with other
threads.
● Even though the OS reclaim system resources from a canceled thread but
will not reclaim all resources.
Continued

2. Deferred cancellation

● One thread indicates that a target thread is to be canceled, but target thread
can check whether it should be terminated or not
● Given an opportunity to terminate. If it wants to terminate it will look for
the point where it can terminate safely
● Pthreads refers to such points as cancellation points
 Signal Handling

● A signal is used in UNIX systems to notify a process that a particular event

has occurred.

● A signal may be received either synchronously or asynchronously.

● All signals, whether synchronous or asynchronous, follow the same pattern:

1. A signal is generated by the occurrence of a particular event.

2. A generated signal is delivered to a process.

3. Once delivered, the signal must be handled.

Continued

● Synchronous signals are delivered to the processes that performed the

operation that causes the signal.
■ Ex. Illegal memory access, divide by Zero

● Asynchronous signals are generated by an event external to a running

process.
■ Ex. Time expire

● Every signal may be handled by one of two possible handlers:

■ A default signal handler
■ A user-defined signal handler

● The default signal handler will run by the kernel which can perform the
default action to handle the signal.
Continued

● The User-defined handler will override the default actions to handle the signals.
● Some signals can be handled by simply ignoring them and others can be
handled by terminating the program.
● When a process has ‘n’ threads, signals can be delivered to
1. Deliver the signal to the thread to which the signal applies
2. Deliver the signal to every thread in the process
3. Deliver the signal to certain threads in the process
4. Assign a specific thread to receive all signals for the process
 Thread Pools
● Issues of thread are the amount of time required to create the thread, unlimited
threads could exhaust system resources, such as CPU time or memory. One
solution to this issue is to use a thread pool.
● The general idea behind a thread pool is to create a number of threads at process
startup and place them into a pool.
● When a server gets a request for the thread, it awakens a thread from the pool and
if thread is available it assigns the request to it. Once the thread completes its job it
can return back to the pool.
● If thread is not available server can wait.
● Advantages are
1. Servicing a request with an existing thread is usually faster.
2. A thread pool limits the number of threads that exist at any point of time.
 Thread Specific Data

● As we know that, the thread belonging to a process share the data of a

process

● In some circumstances, a thread may need to have its own copy of data
known as thread specific data.

● For ex: Transaction-processing system, in which each transaction has

serviced using separate thread. To associate each thread with its unique
identifier, we could use thread-specific data.
 Scheduler activations

● Both Many-to-many and two-level models require communication to

maintain the appropriate number of kernel threads (to the user threads)
allocated to the application to ensure best performance.

● To achieve this, many systems implementing either the many-to-many or

two-level model place an intermediate data structure between the user and
kernel threads. This data structure—typically known as a lightweight
process or LWPs.
● To the user-thread library, the LWP appears to be a virtual processor on
which the application can schedule a user thread to run.

● Each LWP is attached to a kernel thread, and it is kernel threads that the
operating system schedules to run on physical processors.

● If a kernel thread blocks, the LWP blocks and intern user-level thread
attached to the LWP also blocks.

● The communication between the user-thread library and the kernel is known
as scheduler activation.
Continued

● Scheduler activations provide upcall procedure to notices the application about

certain events. upcall handlers that run on virtual processor are used to handle these
upcalls.

Ex. When an application thread is about to block, a kernel makes an upcall to notices the
application about the blocking of specific thread. The kernel then allocates a new
processor (LWP) to the application on which it can run an upcall handler, which saves
the state of the blocking thread and relinquishes the virtual processor on which the
blocking thread is running. The upcall handler then schedules another thread that is
eligible to run on the new virtual processor.
Continued
Process Scheduling
Module 2
 Introduction

● CPU Scheduling is the basis of multiprogrammed OS

● By switching the CPU among processes, the OS can make the computer
more productive

● In this chapter we discuss the basic CPU scheduling concepts , different

Scheduling algorithms and also consider the problem of selecting an
algorithm for a particular system
 Basic concepts
● In a single processor system, only one process can run at a time and others
has to wait for the CPU. When that process needs to perform I/O request the
CPU may sit idle and all this waiting time may get wasted.
● In multiprogramming, the maximum CPU utilization is obtained by,
1. Keeping several processes in memory at one time.
2. Every time a running process has to wait, another process can take over use of
the CPU
3. Short-term scheduler will assign the process to the processer.

● The problem of determining when processors should be assigned and to which

processes is called processor scheduling or CPU scheduling.
Continued

● When more than one process is runnable, the operating system must decide
which one first.

● The part of the operating system concerned with the above decision is called
the scheduler

● Algorithm used to achive the above decision is called the scheduling

algorithm.
 CPU-I/O Burst Cycle

● The success of CPU Scheduling depends on an observed property of

processes

● Process execution consists of a cycle of a CPU time burst and an I/O time
burst (i.e. wait).

● Processes alternate between these two states (i.e., CPU burst and I/O
burst). Eventually, the final CPU burst ends with a system request to
terminate execution
Figure: Alternating sequence of CPU and I/O bursts & CPU
Burst Histogram
 CPU Scheduler

● Whenever the CPU becomes idle, the OS must select 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 the process from the processes in memory that are
ready to execute and allocate the CPU to that process
 Preemptive & Non-Preemptive Scheduling

● CPU scheduling decision may take place under the following four
circumstances:
1. When a process switches from running to waiting state.
For ex: as a result of I/O request or the invocation of wait for the termination
of one of the child processes
2. When a process switches from running to ready state.
For ex: when an interrupt occurs
3. When a process switches from waiting to ready state.
For example at completion of I/O
4. When a processes switches from running to terminated state.
Continued

● For circumstances 1 and 4, there is no choice in terms of scheduling. A new

process must be selected for execution - scheduling scheme is non
preemptive or cooperative

● For circumstances 2 and 3 there is a choice between preemptive and non-

preemptive scheduling

● Under nonpreemptive scheduling , once the CPU has been allocated to a

process, the process keeps the CPU until it releases the CPU either by
terminating or by switching to the waiting state.
Continued…

● Preemptive is not allowed in following conditions

1. Processes are accessing the shared data
2. Process is executing in kernel mode
3. Interrupts occurring during crucial OS activities
 Dispatcher
● The dispatcher is the module that gives control of the CPU to the process
selected by the short-term scheduler. This function involves the following:
1. Switching context
2. Switching to user mode
3. Jumping to the proper location in the user program to restart that program
● The time it takes for the dispatcher to stop one process and start another
process is called dispatch latency.
● The dispatcher needs to run as fast as possible, since it is invoked during
process context switch.
 Scheduling Criteria
● Different CPU scheduling algorithms may have different properties and the choice of
a particular algorithm may favor one class of processes over another.
● Many criteria have been suggested for choosing which CPU scheduling algorithms
to use in a particular situation. They are as follows,
1. CPU utilization –The percentage of time that the CPU is busy in executing a process.
CPU utilization can range from 0 to 100 percent.
In a real systems, it should range from 40% ( for a lightly loaded system) to 90%
( for a heavily loaded system)

2. Throughput – Number of processes that are completed per time unit.

For long processes this rate is one process per hour and for short processes this rate is 10
processes per hour
Continued
3. Response time – Amount of time it takes from when a request was submitted
until the first response occurs (but not the time it takes to output the entire
response).

4. Waiting time –The sum of amount of time a process wait in ready queue
(doesn’t affect the amount of time during which a process executes or does I/O;)
5. Turnaround time – The amount of time to execute a particular process from
the time of submission through the time of completion. (completion time – arrival
time)
 Scheduling Algorithm Optimization Criteria
● Max CPU utilization
● Max throughput
● Min turnaround time
● Min waiting time
● Min response time (minimize the variance)
 Scheduling Algorithms
● CPU Scheduling deals with the problem of deciding which of the
processes in the ready queue is to be allocated the CPU
 Terminologies for CPU scheduling algorithms:
1. Arrival Time: Time at which the process arrives in the ready queue.
2. Completion Time: Time at which process completes its execution.
3. Burst Time: Time required by a process for CPU execution.
4. Turn Around Time: Time Difference between completion time and arrival time.
Turn Around Time = Completion Time – Arrival Time
5. Waiting Time(W.T): Time Difference between turn around time and burst time.
Waiting Time = Turn Around Time – Burst Time
First-Come, First-Served Scheduling

● FCFS is the very simplest scheduling algorithm.

● The process that requests the CPU first is allocated the CPU first.
● The implementation of the FCFS policy is easily managed with a FIFO queue.
When a process enters the ready queue, its PCB is linked onto the tail of the
queue.
● When the CPU is free, it is allocated to the process at the head of the queue.
● The FCFS scheduling algorithm is non-preemptive.
● FCFS may experience convoy effect where the shorter CPU burst / IO burst
processes needs to wait for one long-running process to finish using the CPU
or any device. This problem results in lower CPU and device utilization.
(shown in Ex.1)
● The higher utilization might be possible if the short processes were allowed to
run first.( shown in Ex.2)
 Example on FCFS

1) Assume processes arrives in the order P1,P2,P3 at t=0. Show the FCFS
result on Gantt chart.
Process Burst time
P1 24
P2 3
P3 3
Gantt chart:
The average waiting time= ((0-0)+(24-0)+(27-0))/3= 17 ms
The average turnaround time=((24-0)+(27-0)+(30-0))/3= 27 ms
 Shortest-Job-First Scheduling
● The SJF algorithm associates with each process the length of its next CPU
burst.
● When the CPU becomes available, it is assigned to the process that has the
smallest next CPU burst (in the case of matching bursts, FCFS is used)
● The SJF scheduling algorithm is provably optimal.
● The difficulty with the SJF algorithm is knowing the length of the next
CPU request.
● SJF algorithm cannot be implemented at the level of short-term CPU
scheduling. There is no way to know the length of the next CPU burst.
Determining Length of Next CPU Burst
● SJF algorithm Can only estimate the length of the next CPU burst– should be
similar to the previous one
○ Then pick process with shortest predicted next CPU burst
● Can be done by using the length of previous CPU bursts, using exponential
averaging
1. t n  actual length of n th CPU burst
2.  n 1  predicted value for the next CPU burst
3.  , 0    1
4. Define :  n+1   t n  1    n .
● Commonly, α set to ½
●  =0
○ n+1 = n
○ Recent history does not count
●  =1
○ n+1 =  tn
○ Only the actual last CPU burst counts

Figure shows an exponential

average with  = 1/2 and 0= 10
● Two schemes:
1. Nonpreemptive – Once the CPU is given to the process, it cannot be preempted until
it completes its CPU burst
2. Preemptive – if a new process arrives with a CPU burst length less than the
remaining time of the current executing process, preempt. This scheme is known as
the Shortest-Remaining-Time-First (SRTF).
 Process Arrival Time Burst Time
P1 0.0 6
P2 0.0 8
P3 0.0 7
P4 0.0 3

● SJF scheduling chart

P4 P1 P3 P2
0 3 9 16 24

● Average waiting time = (3 + 16 + 9 + 0) / 4 = 7ms

 Process Arrival Time Burst Time
P1 0 8
P2 1 4
P3 2 9
P4 3 5
● Preemptive SJF Gantt Chart

P1 P2 P4 P1 P3
0 1 5 10 17 26

● Average waiting time = [(10-1)+(1-1)+(17-2)+5-3)]/4 = 26/4 = 6.5 ms

 Example on SJF
Ex #1: Non-Preemptive SJF(simultaneous arrival)

Process Arrival Time Burst Time

P1 0.0 6
P2 0.0 4
P3 0.0 1
P4 0.0 5

The Gantt chart for the schedule is:

p1 p2 p3 p4

The average waiting time= ((10-0)+(1-0)+(0-0)+(5-0))/4= 4 ms

Average turnaround time = (1 + 5 + 10 + 16)/4 = 8ms (finish time – arrival time)

Ex #2: Preemptive SJF ( SRTF)
Process Arrival Time Burst Time
P1 0.0 7
P2 2.0 4
P3 4.0 1
P4 5.0 4
The Gantt chart for the schedule is:

Average waiting time

= ( [(0 – 0) + (11 - 2)] + [(2 – 2) + (5 – 4)] + (4 - 4) + (7 – 5) )/4
= 9 + 1 + 0 + 2)/4 = 3ms
Average turnaround time = [16 + (7-2) + (5-4) + (11-5)]/4 = 7.25ms
 Priority Scheduling

● The SJF algorithm is a special case of the general priority scheduling algorithm.
● A priority number (integer) is associated with each process.
● The CPU is allocated to the process with the highest priority (smallest CPU burst =
highest priority)
● Priority scheduling can be either preemptive or non-preemptive.
○ A preemptive approach will preempt the CPU if the priority of the newly-arrived
process is higher than the priority of the currently running process
○ A non-preemptive approach will simply put the new process (with the highest
priority) at the head of the ready queue
Contd

● The main problem with priority scheduling is starvation, that is, low priority
processes may never get a chance to execute.
● A solution is aging. As time progresses, the priority of a process waiting for
the long time in the ready queue is increased
 Problems on priority Scheduling
Ex. Consider the following set of processes arriving at t=0, in the order p1, p2,p3,p4,p5
with the burst time as shown. Using priority scheduling we would schedule these
processes as shown in the Gantt chart.(Non-preemptive)
Process Burst time Priority
P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2

Gantt chart

The average waiting time is (6-0)+(0-0)+(16-0)+(18-0)+(1-0)= 8.2 milliseconds.

 Round-Robin Scheduling (preemptive)
● The round-robin (RR) scheduling algorithm is designed especially for
time sharing systems.
● It is similar to FCFS scheduling, but preemption is added to switch between
the processes.
● A small unit of time, called a time quantum or time slice is defined. A time
quantum is generally from 10 to 100 milliseconds.
● The ready queue is treated as a circular queue. The CPU scheduler goes
around the ready queue, allocating the CPU to each process for a time
interval of up to 1time quantum.
● 2 cases may arise for scheduler to pick up the next process in ready queue.
1. The process may have a CPU burst of less than 1 time quantum, where the process
itself will release the CPU voluntarily.
2. The CPU burst of the currently running process is longer than 1 time quantum, the
timer will go off and will cause an interrupt to the OS
● If there are n processes in the ready queue and the time quantum is q, then each
process gets 1/n of the CPU time in chunks of at most q time units at once.
No process waits more than (n-1)q time units.
● The performance of the RR algorithm depends heavily on the size of the time
quantum.
1. Large time quantum -> the RR policy is same as the FCFS policy.
2. Small time quantum -> the RR approach is called processor sharing and creates
the appearance that each of n processes has its own processor running at 1/n the
speed of the real processor.
 Problems on Round Robin Scheduling

Ex. Process Burst time (Assume time quantum=4ms, arrival time is t=0)
P1 24
P2 3
P3 3
The Gantt chart is:

The average waiting time is (10-4)+4+7 / 3= 5.66 milliseconds.

Average turn-around time = (30+7+10) / 3 = 15.6ms
● When the quantum size is too small, the number of context switches increases
which may be really a overhead for the system. It also increases the execution
time required and the average turnaround time.

● One rule of thumb is that 80% of the CPU bursts should be shorter than the
time quantum.
 Problems on Round Robin Scheduling

Ex.2: Process Burst time (Assume time quantum=20ms, arrival time is t=0)
P1 53
P2 17
P3 68
P4 24

The Gantt chart is:

 Problems on Round Robin Scheduling

Average waiting time

= ( [(0 – 0) + (77 - 20) + (121 – 97)] + (20 – 0) + [(37 – 0) + (97 - 57) + (134 – 117)] +
[(57 – 0) + (117 – 77)] ) / 4
= (0 + 57 + 24) + 20 + (37 + 40 + 17) + (57 + 40) ) / 4
= (81 + 20 + 94 + 97)/4
= 292 / 4 = 73 ms

Average turnaround time = (134 + 37 + 162 + 121) / 4 = 113.5 ms

 Multilevel Queue scheduling
● Multi-level queue scheduling is used when processes can be classified into groups.
● For example, foreground (interactive) processes and background (batch)
processes
○ The two types of processes have different response-time requirements and so may have
different scheduling needs.
○ Also, foreground processes may have priority (externally defined) over background
processes.

● A multi-level queue scheduling algorithm partitions the ready queue into several
separate queues.
● The processes are permanently assigned to one queue, generally based on some
property of the process such as memory size, process priority, or process type .
Contd

● Each queue has its own scheduling algorithm

o The foreground queue might be scheduled using an RR algorithm.

o The background queue might be scheduled using an FCFS algorithm.

● In addition, there needs to be scheduling among the queues, which is

commonly implemented as fixed-priority preemptive scheduling.

● The foreground queue may have absolute priority over the background
queue.
● One example of a multi-level queue are the five queues as shown below.
● Each queue has absolute priority over lower priority queues. For example, no
process in the batch queue can run unless the queues above it are empty. And
whenever a new interactive process enters while executing batch processes, the
batch process would be preempted.
● However, this can result in starvation for the processes in the lower priority
queues.
● The solution is to introduce time slice among the queues.
● Each queue gets a certain portion of the CPU time, which it can then
schedule among its various processes.
o The foreground queue can be given 80% of the CPU time for RR
scheduling.
o The background queue can be given 20% of the CPU time for FCFS
scheduling.
 Multilevel Feedback Queue scheduling
● The multilevel queue scheduling has the advantage of low scheduling
overhead, but it is inflexible. The multilevel feedback-queue scheduling
algorithm, in contrast, allows a process to move between queues.
● The idea is to separate processes according to the characteristics of their CPU
bursts. If a process uses too much CPU time,it will be moved to a lower-
priority queue. This scheme leaves I/O-bound and interactive processes in the
higher-priority queues.
● A process that waits too long in a lower-priority queue may be moved to a
higher-priority queue. This form of aging prevents starvation.
Contd

● A multilevel-feedback-queue scheduler is defined by the following

parameters:
1. Number of queues.
2. Scheduling algorithms for each queue.
3. Method used to determine when to promote a process.
4. Method used to determine when to demote a process.
5. Method used to determine which queue a process will enter when that
process needs service
● For example, consider a multilevel feedback-queue scheduler with three
queues numbered from 0 to 2 (Figure). The scheduler first executes all
processes in queue 0. Only when queue 0 is empty it will execute processes
in queue 1 and so on.
Contd
● A new job enters queue Q0 (RR) and is placed at the end. When it gains the CPU, the
job receives 8 milliseconds. If it does not finish in 8 milliseconds, the job is moved to
the end of queue Q1.
● A Q1 (RR) job receives 16 milliseconds. If it still does not complete, it is preempted
and moved to queue Q2 (FCFS).
● Processes in queue 2 are run on an FCFS basis but are run only when queues 0 and 1
are empty.
 Multiple Processor scheduling
● If multiple CPUs are available, load sharing among them becomes
possible. But the scheduling problem becomes more complex.

● We consider the systems in which the processors are identical

(homogeneous) in terms of their functionality. So we can use any available
processor to run any process in the queue.

● Several concerns need to be consider (like scheduling, load balancing,

affinity etc.) in multiprocessor system

● Approaches to Multiple Processor scheduling

Two approaches: Asymmetric processing and symmetric processing.
Asymmetric multiprocessing (ASMP)
● One processor can be a master processor which can handles all scheduling
decisions, I/O processing, and other system activities.
● The other processors execute only user code.
● Because only one processor accesses the system data structures, the need for data
sharing is reduced.

Symmetric multiprocessing (SMP)

● Each processor schedules itself.
● All processes may be in a common ready queue or each processor may have its
own ready queue.
● Either way, each processor examines the ready queue and selects a process to
execute.
● Virtually all modern operating systems support SMP, including Windows XP,
Solaris, Linux, and Mac OS X.
 Thread Scheduling
● User level threads are managed by the thread library and the kernel is
unaware of them
● To run on a CPU. user level threads must be mapped to an associated kernel
level thread, this mapping may be indirect and may use a light weight
process
● Many-to-one and many-to-many models, thread library schedules user-
level threads to run on LWP
● We discuss scheduling issues involving user level and kernel level
threads
 Contention scope
● One distinction between user level and kernel level thread lies in how they are
scheduled.
● On system, implementing many to one and many to many models, the thread library
schedules user level threads on an available LWP. This scheme is known as process
contention scope (PCS)
● Here competition for the CPU takes place among threads of the same process
● To decide which kernel thread to schedule onto a CPU, the kernel uses system
contention scope(SCS)
● Competition for the CPU with the SCS scheduling takes place among all the threads
in the system