Process management

What are we going to learn?

• Processes : Concept of processes, process scheduling, co-operating processes, inter-process

communication.

• CPU scheduling : scheduling criteria, preemptive & non-preemptive scheduling, scheduling

algorithms (FCFS, SJF, RR, priority), algorithm evaluation, multi-processor scheduling.

• Process Synchronization : background, critical section problem, critical region, synchronization

hardware, classical problems of synchronization, semaphores.

• Threads : overview, benefits of threads, user and kernel threads.

• Deadlocks : system model, deadlock characterization, methods for handling deadlocks, deadlock
prevention, deadlock avoidance, deadlock detection, recovery from deadlock.
 Process concept
Memory
• Process is a dynamic entity
– Program in execution Disk
User
• Program code program
– Contains the text section
• Program becomes a process when
– executable file is loaded in the memory
– Allocation of various resources
• Processor, register, memory, file, devices
• One program code may create several processes
– One user opened several MS Word
– Equivalent code/text section
– Other resources may vary
 Process State
• As a process executes, it changes state
– new: The process is being created
– ready: The process is waiting to be assigned to
a processor
– running: Instructions are being executed
– waiting: The process is waiting for some event
to occur
– terminated: The process has finished execution
 Job pool
Process State diagram

Single
processor

Multiprogramming 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
 Job pool Process State diagram

Multitasking/Time sharing
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
 How to represent a process?
• Process is a dynamic entity
– Program in execution
• Program code
– Contains the text section
• Program counter (PC)
• Values of different registers
– Stack pointer (SP) (maintains process stack)
• Return address, Function parameters
– Program status word (PSW) C Z O S I K
– General purpose registers
• Main Memory allocation
– Data section
• Variables
– Heap
• Dynamic allocation of memory during process execution
 Process Control Block (PCB)
• Process is represented in the operating system
by a Process Control Block
Information associated with each process
• Process state
• Program counter
• CPU registers
– Accumulator, Index reg., stack pointer, general
Purpose reg., Program Status Word (PSW)
• CPU scheduling information
– Priority info, pointer to scheduling queue
• Memory-management information
– Memory information of a process
– Base register, Limit register, page table, segment table
• Accounting information
– CPU usage time, Process ID, Time slice
• I/O status information
– List of open files=> file descriptors
– Allocated devices
 Process Representation in Linux
Represented by the C structure task_struct
pid t pid; /* process identifier */
long state; /* state of the process */
unsigned int time slice /* scheduling information */
struct task struct *parent; /* this process’s parent */
struct list head children; /* this process’s children */
struct files struct *files; /* list of open files */
struct mm_struct *mm; /* address space of this pro */

Doubly
linked list
 CPU Switch From Process to Process

Context switch
 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 via a context switch.

• Context of a process represented in the PCB

• Context-switch time is overhead; the system does not do

useful work while switching
– The more complex the OS and the PCB -> longer the context
switch

• Time dependent on hardware support

– Some hardware provides multiple sets of registers per CPU ->
multiple contexts loaded at once
 Scheduling queues

• 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
 Scheduling queues

Job queue

Ready queue

Device queue
 Ready Queue And Various
I/O Device Queues
Queues are linked list of PCB’s

Device queue

Many processes
are waiting for
disk
 Process Scheduling
• We have various queues
• Single processor system
– Only one CPU=> only one running process
• Selection of one process from a group of
processes
– Process scheduling
 Process Scheduling
• Scheduler
– Selects a process from a set of processes
• Two kinds of schedulers
1. Long term schedulers, job scheduler
– A large number of processes are submitted (more than
memory capacity)
– Stored in disk
– Long term scheduler selects process from job pool and
loads in memory
2. Short term scheduler, CPU scheduler
– Selects one process among the processes in the
memory (ready queue)
– Allocates to CPU
Long Term Scheduler

CPU scheduler
 Representation of Process Scheduling
CPU scheduler selects
a process Dispatched (task of
Dispatcher)

Parent at
wait()
 Dispatcher
• Dispatcher module gives control of the CPU to
the process selected by the short-term
scheduler; this involves:
– switching context
– switching to user mode
– jumping to the proper location in the user
program to restart that program

• Dispatch latency – time it takes for the

dispatcher to stop one process and start
another running
 Creation of PCB
a.out Shell

Create
initial Child Shell
PCB

Exce()

Loader (Loads program image in

memory)

Update PCB
Context switch

Insert in ready Allocate CPU

queue
 Schedulers
• Scheduler
– Selects a process from a set
• Long-term scheduler (or job scheduler) –
selects which processes should be brought
into the ready queue
• Short-term scheduler (or CPU scheduler) –
selects which process should be executed
next and allocates CPU
– Sometimes the only scheduler in a system
Schedulers: frequency of execution
• Short-term scheduler is invoked very frequently (milliseconds)
 (must be fast)
– After a I/O request/ Interrupt
• Long-term scheduler is invoked very infrequently (seconds,
minutes)  (may be slow)
– The long-term scheduler controls the degree of
multiprogramming

• Processes can be described as either:

– I/O-bound process – spends more time doing I/O than
computations, many short CPU bursts
• Ready queue empty
– CPU-bound process – spends more time doing computations; few
very long CPU bursts
• Devices unused
• Long term scheduler ensures good process mix of I/O and CPU
bound processes.
Addition of Medium Term Scheduling
disk Swap Space

Swapper
 ISR for context switch
Current <- PCB of current process
Context_switch()
{
Disable interrupt;
switch to kernel mode
Save_PCB(current);
Insert(ready_queue, current);
next=CPU_Scheduler(ready_queue);
remove(ready_queue, next);
Dispatcher(next);
switch to user mode;
Enable Interrupt;

}
Dispatcher(next)
{
Load_PCB(next); [update PC]

}
 Interprocess Communication
• Processes within a system may be independent or cooperating

• Cooperating process can affect or be affected by other processes,

including sharing data

• Cooperating processes require an interprocess communication

(IPC) mechanism that will allow them to exchange data— that is,
send data to and receive data from each other.

• Cooperating processes need interprocess communication (IPC)

• Two models of IPC

– Shared memory
– Message passing
 Interprocess Communication

In the shared-memory model, a region of In the message-passing model, communication

memory that is shared by the cooperating takes place by means of messages exchanged
processes is established. between the cooperating processes
Processes can then exchange information (Kernel involvement, slow)
by reading and writing data to the shared
region.
 CPU Scheduling

• Describe various CPU-scheduling

algorithms

• Evaluation criteria for selecting a CPU-

scheduling algorithm for a particular
system
 Basic Concepts
• Maximum CPU utilization obtained with
multiprogramming
– Several processes in memory (ready queue)
– When one process requests I/O, some other
process gets the CPU
– Select (schedule) a process and allocate CPU
Observed properties of Processes

• CPU–I/O Burst Cycle

• Process execution consists

of a cycle of CPU execution
and I/O wait

• Study the duration of CPU

bursts
 Histogram of CPU-burst Times

Utility of CPU
scheduler

CPU bound
process

I/O bound
process

Large number of short CPU bursts and small number of long CPU
bursts
 Preemptive and non preemptive
• Selects from among the processes in ready
queue, and allocates the CPU to one of them
– Queue may be ordered in various ways (not
necessarily FIFO)
• CPU scheduling decisions may take place when
a process:
1. Switches from running to waiting state
2. Switches from running to ready state
3. Switches from waiting to ready
4. Terminates
• Scheduling under 1 and 4 is nonpreemptive
• All other scheduling is preemptive
Long Term Scheduler

CPU scheduler
 Preemptive scheduling
Preemptive scheduling
Results in cooperative processes
Issues:
– Consider access to shared data
• Process synchronization
– Consider preemption while in kernel mode
• Updating the ready or device queue
• Preempted and running a “ps -el”

Race condition
 Scheduling Criteria
• CPU utilization – keep the CPU as busy as possible

• Throughput – # of processes that complete their execution per

time unit

• Turnaround time – amount of time to execute a particular

process

• Waiting time – amount of time a process has been waiting in

the ready queue

• Response time – amount of time it takes from when a request

was submitted until the first response is produced, not output
 Scheduling Algorithm Optimization Criteria

• Max CPU utilization

• Max throughput
• Min turnaround time
• Min waiting time
• Min response time

• Mostly optimize the average

• Sometimes optimize the minimum or maximum value
• Minimize max response time

• For interactive system, variance is important

• E.g. response time
• System must behave in predictable way
 Scheduling algorithms
• First-Come, First-Served (FCFS) Scheduling

• Shortest-Job-First (SJF) Scheduling

• Priority Scheduling

• Round Robin (RR)

 First-Come, First-Served (FCFS) Scheduling

• Process that requests CPU first, is allocated the CPU first

• Ready queue=>FIFO queue
• Non preemptive
• Simple to implement

Performance evaluation
• Ideally many processes with several CPU and I/O bursts

• Here we consider only one CPU burst per process

 First-Come, First-Served (FCFS) Scheduling

Process Burst Time

P1 24
P2 3
P3 3
• Suppose that the processes arrive in the order: P1 , P2
, P3
The Gantt Chart for the schedule is:
P1 P2 P3

0 24 27 30
• Waiting time for P1 = 0; P2 = 24; P3 = 27
• Average waiting time: (0 + 24 + 27)/3 = 17
 FCFS Scheduling (Cont.)
Suppose that the processes arrive in the order:
P2 , P3 , P1
• The Gantt chart for the schedule is:

P2 P3 P1

0 3 6 30

• Waiting time for P1 = 6; P2 = 0; P3 = 3

• Average waiting time: (6 + 0 + 3)/3 = 3
• Much better than previous case
• Average waiting time under FCFS heavily depends on process arrival
time and burst time
• Convoy effect - short process behind long process
– Consider one CPU-bound and many I/O-bound processes
 Shortest-Job-First (SJF) Scheduling
• Associate with each process the length of
its next CPU burst
– Allocate CPU to a process with the smallest
next CPU burst.
– Not on the total CPU time
• Tie=>FCFS
 Example of SJF
ProcessArrival Time Burst Time
P1 0.0 6
P2 2.0 8
P3 4.0 7
P4 5.0 3
• SJF scheduling chart

P4 P1 P3 P2

0 3 9 16 24

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

Avg waiting time for FCFS?

 SJF
• SJF is optimal – gives minimum average
waiting time for a given set of processes
(Proof: home work!)
• The difficulty is knowing the length of the next
CPU request
• Useful for Long term scheduler
– Batch system
– Could ask the user to estimate
– Too low value may result in “time-limit-exceeded error”
 Preemptive version
Shortest-remaining-time-first
• Preemptive version called shortest-remaining-time-first
• Concepts of varying arrival times and preemption to the analysis
ProcessA arri Arrival TimeT 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 msec

Avg waiting time for non preemptive?

 Determining Length of Next CPU Burst
• Estimation of the CPU burst length – should be similar
to the previous burst
– Then pick process with shortest predicted next CPU burst
• Estimation can be done by using the length of
previous CPU bursts, using time series analysis
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 : Boundary
 n +1 =  tn + (1 −  ) n . cases α=0, 1

• Commonly, α set to ½
 Examples of Exponential Averaging
•  =0
– n+1 = n
– Recent burst time does not count
•  =1
– n+1 = tn
– Only the actual last CPU burst counts
• If we expand the formula, we get:
n+1 =  tn+(1 - ) tn-1 + …
+(1 -  )j  tn -j + …
+(1 -  )n +1 0
• Since both  and (1 - ) are less than or equal to 1,
each successive term has less weight than its
predecessor
 Prediction of the Length of the
Next CPU Burst

0 1 2 3 6
 Priority Scheduling
• A priority number (integer) is associated with each process
• The CPU is allocated to the process with the highest priority
(smallest integer  highest priority)
• Set priority value
nice
– Internal (time limit, memory req., ratio of I/O Vs CPU burst)
– External (importance, fund etc)
• SJF is priority scheduling where priority is the inverse of predicted
next CPU burst time

• Two types
– Preemptive
– Nonpreemptive

• Problem  Starvation – low priority processes may never execute

• Solution  Aging – as time progresses increase the priority of the
process
 Example of Priority Scheduling

ProcessAarri Burst TimeT Priority

P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2
• Priority scheduling Gantt Chart

P2 P5 P1 P3 P4

0 1 6 16 18 19

• Average waiting time = 8.2 msec

 Round Robin (RR)
• Designed for time sharing system
• Each process gets a small unit of CPU time (time quantum q),
usually 10-100 milliseconds.
• After this time has elapsed, the process is preempted and added
to the end of the ready queue.
• Implementation
– Ready queue as FIFO queue
– CPU scheduler picks the first process from the ready queue
– Sets the timer for 1 time quantum
– Invokes despatcher
• If CPU burst time < quantum
– Process releases CPU
• Else Interrupt
– Context switch
– Add the process at the tail of the ready queue
– Select the front process of the ready queue and allocate CPU
 Example of RR with Time Quantum = 4
Process Burst Time
P1 24
P2 3
P3 3

• The Gantt chart is:

P1 P2 P3 P1 P1 P1 P1 P1

0 4 7 10 14 18 22 26 30

• Avg waiting time = ((10-4)+4+7)/3=5.66

 Round Robin (RR)
• Each process has a time quantum T allotted to it
• Dispatcher starts process P0, loads a external counter (timer)
with counts to count down from T to 0
• When the timer expires, the CPU is interrupted
• The context switch ISR gets invoked
• The context switch saves the context of P0
– PCB of P0 tells where to save
• The scheduler selects P1 from ready queue
– The PCB of P1 tells where the old state, if any, is saved
• The dispatcher loads the context of P1
• The dispatcher reloads the counter (timer) with T
• The ISR returns, restarting P1 (since P1’s PC is now loaded as
part of the new context loaded)
• P1 starts running
 Round Robin (RR)
• 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.
• Timer interrupts every quantum to schedule next process
• Performance depends on time quantum q
– q large  FIFO
– q small  Processor sharing (n processes has own CPU
running at 1/n speed)
 Effect of Time Quantum and Context Switch Time
Performance of RR scheduling

• No overhead
• However,
poor response
time

• Too much
overhead!
• q must be large with respect to context switch,
• Slowing the
otherwise overhead is too high
execution time
• q usually 10ms to 100ms, context switch < 10 microsec
 Effect on Turnaround Time
• TT depends on the time quantum and CPU burst time
• Better if most processes complete there next CPU burst in a
single q
• Large q=>
processes in ready
queue suffer
• Small q=>
Completion will
take more time

80% of CPU bursts

should be shorter than
q

Response time Typically, higher average turnaround than SJF,

but better response time
 Turnaround Time
q=1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
P1 P2 P3 P4 P1 P2 P4 P1 P2 P4 P1 P4 P1 P4 P1 P4 P4
`

Avg Turnaround time=

(15+9+3+17)/4=11

0 6 9 10 16 17
P1 P2 P3 P4 P4

(6+9+10+17)/4=10.5
q=6
 Process classification
• Foreground process
– Interactive
– Frequent I/O request
– Requires low response time
• Background Process
– Less interactive
– Like batch process
– Allows high response time
• Can use different scheduling algorithms for two types
of processes ?
 Multilevel Queue
• Ready queue is partitioned into separate queues, eg:
– foreground (interactive)
– background (batch)
• Process permanently assigned in a given queue
– Based on process type, priority, memory req.
• Each queue has its own scheduling algorithm:
– foreground – RR
– background – FCFS
• Scheduling must be done between the queues:
– Fixed priority scheduling; (i.e., serve all from foreground
then from background).
– Possibility of starvation.
 Multilevel Queue Scheduling
• No process in batch queue
could run unless upper
queues are empty

• If new process enters

• Preempt

Another possibility
• Time slice – each queue gets a certain amount of CPU time which it can schedule
amongst its processes; i.e., 80% to foreground in RR
• 20% to background in FCFS
 Multilevel Feedback Queue
• So a process is permanently assigned a queue when
they enter in the system
– They do not move
• Flexibility!
– Multilevel-feedback-queue scheduling
• A process can move between the various queues;
• Separate processes based of the CPU bursts
– Process using too much CPU time can be moved to lower
priority
– Interactive process => Higher priority
• Move process from low to high priority
– Implement aging
 Example of Multilevel Feedback
Queue
Q0
• Three queues:
– Q0 – RR with time quantum 8 milliseconds
Q1
– Q1 – RR time quantum 16 milliseconds
– Q2 – FCFS
Q2
• Scheduling
– A new job enters queue Q0
• When it gains CPU, job receives 8 milliseconds
• If it does not finish in 8 milliseconds, job is moved to queue
Q1
– At Q1 job is again receives 16 milliseconds
• If it still does not complete, it is preempted and moved to
queue Q2
Multilevel Feedback Queues

• Highest Priority to processes

CPU burst time <8 ms
• Then processes >8 and <24
• Multilevel-feedback-queue scheduler defined
by the following parameters:
– number of queues
– scheduling algorithms for each queue
– method used to determine when to upgrade a
process
– method used to determine when to demote a
process
– method used to determine which queue a process
will enter when that process needs service
 Multiple-Processor Scheduling

• If multiple CPUs are available, multiple

processes may run in parallel

• However scheduling issues become

correspondingly more complex.
• Many possibilities have been tried
• As we saw with CPU scheduling with a
single-core CPU
– there is no one best solution
 Multiple-Processor Scheduling
• CPU scheduling more complex when multiple CPUs are
available
• Homogeneous processors within a multiprocessor
• Asymmetric multiprocessing –
– Master server
– only one processor accesses the system data structures,
alleviating the need for data sharing
• Symmetric multiprocessing (SMP) – each processor is self-
scheduling,
• all processes in common ready queue, or each has its own
private queue of ready processes

• Scheduler for each processor examine the ready queue

– select a process to run.
 Multiple-Processor Scheduling

• Permits each processor to schedule

• We have a possible race condition process from its private ready
• Locking to protect the common ready queue
queue from this race condition. • Does not suffer from the possible
• Accessing the shared queue would performance problems
likely be a performance bottleneck • Most common approach on
systems supporting SMP.
• Load balancing
 Multi core processors
• SMP systems have allowed several processes to run in
parallel by providing multiple physical processors.

• Recently, multiple computing cores on the same

physical chip, resulting in a multicore processor.

• Each core maintains its architectural state and thus

appears to the operating system to be a separate
logical CPU

• SMP systems that use multicore processors are faster

and consume less power
– than systems in which each CPU has its own physical chip
 Challenge: Memory stall
• When a processor accesses memory, it spends a
significant amount of time waiting for the data to
become available.
• This situation, known as a memory stall, occurs
primarily because
– modern processors operate at much faster speeds
than memory.
– For cache miss
 Solution: Hardware
threads
• Recent hardware designs have implemented multithreaded
processing cores in which two (or more) hardware threads are
assigned to each core.
• That way, if one hardware thread stalls while waiting for
memory, the core can switch to another thread.
Hyper-threading
• Each hardware thread maintains its
architectural state, such as
instruction pointer and register set,
• Thus appears as a logical CPU that is
available to run a software process.

Contemporary Intel processors—such as

the Intel i7—support two threads per
core,

Oracle Sparc M7 processor supports

eight threads per core, with eight cores
per processor, thus providing the
operating system with 64 logical CPUs
 Dual scheduling
• It is important to note that
• a processing core can only execute one
hardware thread at a time.
– resources of the physical core (such as caches and
pipelines) must be shared among its hardware
threads
• Multithreaded, multicore processor actually
requires two different levels of scheduling
Dual scheduling
• The scheduling decisions that
must be made by the operating
system as it chooses which
software process to run on each
hardware thread (logical CPU).

• For this level of scheduling, the

operating system may choose
any scheduling algorithm
• A second level of scheduling
specifies which hardware
thread to run on a core.

• One approach is to use a simple

round-robin algorithm to
schedule a hardware thread to
the processing core.

• This is the approach adopted by

the UltraSPARC T3.

• Another approach is used by the

Intel Itanium

• Assigned to each hardware

thread is a dynamic urgency
value ranging from 0 to 7
 Problem 1

Combine round-robin and priority scheduling in such a way that the system
executes the highest-priority process and runs processes with the same
priority using round-robin scheduling (q=2).
Solution 1
 Problem 2
Consider three processes (process id 0, 1, 2 respectively) with compute time bursts 2, 4 and 8
time units. All processes arrive at time zero. Consider the longest remaining time first (LRTF)
scheduling algorithm. In LRTF ties are broken by giving priority to the process with the lowest
process id. Compute average turn around time

Process AT BT TAT
P0 0 2

P1 0 4

P2 0 8
 Solution 2
2. Consider three processes (process ID 0,1,2 respectively) with compute time bursts 2,4 and 8 time units. All processes
arrive at time zero. Consider the longest remaining time first (LRTF) scheduling algorithm. In LRTF, ties are broken by
giving priority to the process with the lowest process ID. The average turnaround time is:

P2 P2 P2 P2 P1 P2 P1 P2 P0 P1 P2 P0 P1 p2

PID A.T B.T C.T T.A.T W.T A.T. Arrival Time

P0 0 2 12 12 10 B.T. Burst Time
C.T. Completion Time.
P1 0 4 13 13 9 T.A.T. Turn Around Time
P2 0 8 14 14 6 W.T. Waiting Time.
Average TAT = 39/3 = 13
TOTAL 39 25
units
 Problem 3
Process 0: CPU-bound (each CPU burst is 100ms)
Processes 1--5: IO bound (10ms CPU burst),IO time:
80ms
All processes are available at t = 0.
FCFS: find out when CPU becomes idle for the first
time.
RR: Take time quantum q = 10ms. Again find out
when the CPU becomes idle for the first time.
Solution 3
 Problem 4
Consider the following set of processes, with the arrival times and the
CPU-burst times given in milliseconds. What is the average turnaround
time for these processes with the preemptive shortest remaining
processing time first (SRPT) algorithm?
3. Consider the following set of processes, with the arrival times and the CPU-burst times given in milliseconds. What is the
average turnaround time for these processes with the preemptive shortest remaining processing time first (SRPT)
algorithm?
Process Arrival Time Burst Time
P1 0 5
P2 1 3
P3 2 3
P4 4 1

Average turnaround time = 12 + 3 + 6 + 1 4 = 22 4 = 5.5

Answer: P1 P2 P4 P3 P1
0 1 4 5 8 12

Process Waiting Time = Turnaround Time =

(Turnaround Time – Burst Time) (Completion Time – Arrival Time)
P1 7 12
P2 0 3
P3 3 2
P4 0 1
]
 Interprocess Communication
• Processes within a system may be
independent or cooperating
• Cooperating process can affect or be affected
by other processes, including sharing data

• Cooperating processes need interprocess

communication (IPC)
• Two models of IPC
– Shared memory
– Message passing
 Producer-Consumer Problem
• Paradigm for cooperating processes, producer process
produces information that is consumed by a consumer
process

0 X out Consumer
1 A
Buffer empty=>
in=out 2 B
3 C
Buffer full=>
4 in Producer
(in+1)%size=out
5

• 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;
 Bounded-Buffer – Producer

while (true) {
/* Produce an item */
while (((in + 1) % BUFFER SIZE) == out)
; /* do nothing -- no free buffers */
buffer[in] = item;
in = (in + 1) % BUFFER SIZE;
}
Bounded Buffer – Consumer
while (true) {
while (in == out)
; // do nothing -- nothing to consume

// remove an item from the buffer

item = buffer[out];
out = (out + 1) % BUFFER SIZE;
return item;
}
 Interprocess Communication
Race Conditions
Printer
daemon

File 1

File 2

Two processes want to access shared memory at same time

 Interprocess Communication
Process A Race Conditions
Next_free_slot=7

File 1

File 2

Two processes want to access shared memory at same time

 Interprocess Communication
Process A Race Conditions
Next_free_slot=7

File 1

Process B
File 2
Next_free_slot=7

Two processes want to access shared memory at same time

 Interprocess Communication
Process A Race Conditions
Next_free_slot=7

File 1
File 2 8

Process B

Next_free_slot=8

Two processes want to access shared memory at same time

 Interprocess Communication
Process A Race Conditions
Next_free_slot=8

File 1
File 1 8

Next_free_slot=8 Race condition

Two processes want to access shared memory at same time

 Race condition
• Race condition
– Two or more processes are reading or writing
some shared data and the final result depends on
who runs precisely when

– In our former example, the possibilities are

various

– Hard to debug
 Critical Section Problem
• Critical region
– Part of the program where the shared memory is
accessed

• Mutual exclusion
– Prohibit more than one process from reading and
writing the shared data at the same time
 Critical Section Problem
• Consider system of n processes {p0, p1, … pn-1}
• Each process has critical section segment of code
– Process may be changing common variables, updating
table, writing file, etc
– When one process in critical section, no other may be
in its critical section
• Critical section problem is to design protocol to
solve this
• Each process must ask permission to enter critical
section in entry section, may follow critical
section with exit section, then remainder section
Critical Section Problem
do {

entry section

critical section

exit section

remainder section

} while (TRUE);

General structure of a typical process Pi 95

 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 only the processes outside remainder section (i.e. the
processes competing for critical section, or exit section) can
participate in deciding which process will enter CS next
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
Critical Section Problem
do {

entry section

critical section

exit section

remainder section

} while (TRUE);

General structure of a typical process Pi 97

Critical Section Problem

Mutual exclusion using critical regions

 Mutual Exclusion

• Disable interrupt
– After entering critical region, disable all interrupts
– Since clock is just an interrupt, no CPU
preemption can occur
– Disabling interrupt is useful for OS itself, but not
for users…
 Mutual Exclusion with busy waiting
• Lock variable
– A software solution
– A single, shared variable (lock)
– before entering critical region, programs test the
variable,
– if 0, enter CS;
– if 1, the critical region is occupied
While(true)
{
– What is the problem? while(lock!=0);
Lock=1
CS()
Lock=0
Non-CS()
}
 Concepts
• Busy waiting
– Continuously testing a variable until some value
appears

• Spin lock
– A lock using busy waiting is call a spin lock

• CPU time wastage!

Mutual Exclusion with Busy Waiting : strict
alternation

Proposed solution to critical region problem

(a) Process 0. (b) Process 1.
1.Mutual exclusion is preserved? Y
2.Progress requirement is satisfied? N
3.Bounded-waiting requirement is met? N
 Peterson’s Solution
• Two process solution

• The two processes share two variables:

– int turn;
– Boolean interested [2]

• The variable turn indicates whose turn it is to enter the

critical section

• The interested array is used to indicate if a process is

interested to enter the critical section.
• interested[i] = true implies that process Pi is interested!
 Mutual Exclusion with Busy Waiting (2) : a
workable method

Peterson's solution for achieving mutual exclusion

 Algorithm for Process Pi
do {
interested[i] = TRUE;
turn = j ;
while (interested[j] && turn == j);
critical section
interested[i] = FALSE;
remainder section
} while (TRUE);
Provable that
1. Mutual exclusion is preserved Does this alter the
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met sequence?
 Hardware Instruction Based Solutions
Multiprocessor system
• Some architectures provide special instructions
that can be used for synchronization

• TSL: Test and modify the content of a word

atomically

TSL Reg, lock

{
Reg= lock;
lock = true;
}
Hardware Instruction Based Solutions

Does it satisfy all the conditions?

Entering and leaving a critical region using the

TSL instruction
 System call version
• Special system call that can be used for
synchronization

• TestAndSet: Test and modify the content of a

word atomically

boolean TestAndSet (boolean &target) {

boolean v = target;
target = true;
return v;
}
Mutual Exclusion with Test-and-Set
• Shared data:
boolean lock = false; Does it satisfy all the conditions?

• Process Pi
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
}
Swap Instruction
 Concepts
• Busy waiting
– Continuously testing a variable until some value
appears

• Spin lock
– A lock using busy waiting is call a spin lock

• CPU time wastage!

• Drawback of Busy waiting
– A lower priority process has entered critical region
– A higher priority process comes and preempts the
lower priority process, it wastes CPU in busy
waiting, while the lower priority don’t come out
– Priority inversion problem
 Producer-consumer problem
• Two processes share a common, fixed-sized
buffer

• Producer puts information into the buffer

• Consumer takes information from buffer

• A simple solution
Sleep and Wakeup
 Producer-Consumer Problem

• What can be the problem?

• Signal missing
– Shared variable: counter
– When consumer read count
with a 0 but didn’t fall asleep
in time
– then the signal will be lost

Producer-consumer problem with fatal race condition

 Tasks
• We must ensure proper process
synchronization
– Stop the producer when buffer full
– Stop the consumer when buffer empty

• We must ensure mutual exclusion

– Avoid race condition

• Avoid busy waiting

 Semaphore
• Widely used synchronization tool
• Does not require busy-waiting
– CPU is not held unnecessarily while the process is waiting
• A Semaphore S is
– A data structure with an integer variable S.value and a queue S.list of
processes (shared variable)
– The data structure can only be accessed by two atomic operations,
wait(S) and signal(S) (also called down(S), P(S) and Up(s), V(S))

• Value of the semaphore S = value of the integer S.value

typedef struct {
int value;
struct process *list;
} semaphore
 Semaphore
Wait(S) S<= semaphore variable
• When a process P executes the wait(S) and finds
• S==0
– Process must wait => block()
– Places the process into a waiting queue associated with S
– Switch from running to waiting state
• Otherwise decrement S

Signal(S)
When a process P executes the signal(S)
– Check, if some other process Q is waiting on the semaphore S
– Wakeup(Q)
– Wakeup(Q) changes the process from waiting to ready state
• Otherwise increment S
 Semaphore (wait and signal)
• Implementation of wait:
wait(semaphore *S) { List of PCB
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
} Atomic/
• Implementation of signal: Indivisible
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P); Note: which process is picked
} for unblocking may depend on
} policy.
 Usage of Semaphore
• Counting semaphore – integer value can range over
an unrestricted domain
– Control access to a shared resource with finite elements
– Wish to use => wait(S)
– Releases resource=>signal(S)
– Used for synchronization
• Binary semaphore – integer value can range only
between 0 and 1
– Also known as mutex locks
– Used for mutual exclusion
 Ordering Execution of Processes using
Semaphores (Synchronization)
• Execute statement B in Pj only after statement A
executed in Pi
• Use semaphore flag initialized to 0
• Code:
Pi Pj
 
Stmt. A wait(flag)
signal(flag) Stmt. B

• Multiple such points of synchronization can be

enforced using one or more semaphores
 Semaphore: Mutual exclusion

• Shared data:
semaphore mutex; /* initially mutex = 1 */

• Process Pi:

do {
wait(mutex);

critical section

signal(mutex);

remainder section

} while (1);
 Producer-consumer problem
: Semaphore
• Solve producer-consumer problem
– Full: counting the slots that are full; initial value
0
– Empty: counting the slots that are empty, initial
value N
– Mutex: prevent access the buffer at the same
time, initial value 1 (binary semaphore)

– Synchronization & mutual exclusion

Semaphores
 P0 P1
wait (S); wait (Q);
wait (Q); wait (S);
. .
. .
. .
signal (S); signal (Q);
signal (Q); signal (S);

Let S and Q be two semaphores initialized to 1

 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
– LIFO queue
– A process may never be removed from the semaphore queue
in which it is suspended
Tutorial problems
 Problem 1

Does this solution work?

 Problem 2

Does this solution work?

 Algorithm for Process Pi
do {
interested[i] = TRUE;
turn = j ;
while (interested[j] && turn == j);
critical section
interested[i] = FALSE;
remainder section
} while (TRUE);
Provable that
1. Mutual exclusion is preserved Does this alter the
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met sequence?
CASwap Instruction
 Problem 3: Atomic increment using
CAS
Implement atomic increment using CAS
Atomic increment using CAS
Problem 4: Mutex Lock
available = 1
acquire()
{ while(CAS(available, 1, 0)==0);
}
 Problem 5: Does TSL and CAS
Satisfies all properties of critical section
solution?
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
}
 System call version
• Special system call that can be used for
synchronization

• TestAndSet: Test and modify the content of a

word atomically

boolean TestAndSet (boolean &target) {

boolean v = target;
target = true;
return v;
}
Mutual Exclusion with Test-and-Set
• Shared data:
boolean lock = false; Does it satisfy all the conditions?

• Process Pi
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
}
Swap Instruction
 Readers-Writers Problem
• A database is shared among a number of concurrent
processes
– Readers – only read the data set; they do not perform any updates
– Writers – can both read and write

• Problem – allow multiple readers to read at the same time

– Only one single writer can access the shared data at the same time

• Several variations of how readers and writers are treated – all

involve priorities

• Shared Data
– Database
– Semaphore mutex initialized to 1
– Semaphore wrt initialized to 1
– Integer readcount initialized to 0
Writer Readers-Writers Problem

R R R

Writer
• Task of the writer
• Just lock the
dataset and write

Reader
• Task of the first reader
• Lock the dataset
• Task of the last reader
• Release the lock
• Wakeup the any waiting writer
R R R
 Readers-Writers Problem (Cont.)
• The structure of a writer process

do {
wait (wrt) ;

// writing is performed

signal (wrt) ;
} while (TRUE);
 Readers-Writers Problem (Cont.)
• The structure of a reader process
do {
wait (mutex) ;
readcount ++ ;
if (readcount == 1)
wait (wrt) ;
signal (mutex)

// reading is performed

wait (mutex) ;
readcount - - ;
if (readcount == 0)
signal (wrt) ;
signal (mutex) ;
} while (TRUE);
 Readers-Writers Problem (Cont.)

• Models database access

• Current solution
– Reader gets priority over writer
• Home work
– Writer gets priority
Dining Philosophers Problem
Dining Philosophers Problem
First solution

• Take_fork() waits until the fork is

available
• Available? Then seizes it

• Ensure that two neighboring philosopher should not seize the same fork
Dining Philosophers Problem
Each fork is implemented as a semaphore

• The structure of Philosopher i: Semaphore fork [5]

initialized to 1
do {
wait ( fork[i] );
wait ( fork[ (i + 1) % 5] );

// eat Ensures no two neighboring

philosophers can eat
signal ( fork[i] ); simultaneously
signal (fork[ (i + 1) % 5] );

// think

} while (TRUE);

• What is the problem with this algorithm?

Dining Philosophers Problem
First solution

• Take_fork() waits until the fork is

available
• Available? Then seizes it

• Suppose all of them take the left fork simultaneously

• None of them will get the right fork
• Deadlock
Dining Philosophers Problem
Second solution

• After taking the left fork, philosopher checks to see if right fork is available
• If not, puts down the left fork

Limitation

• All of them start simultaneously, pick up the left forks

• Seeing that their right forks are not available
• Putting down their left fork
• Starvation

• Random delay (Exponential backoff) not going to help for critical systems
Dining Philosophers Problem
Third solution

Wait(mutex);

signal(mutex);

Poor resource utilization

 Dining Philosophers Problem
Final solution
For each philosopher, maintain state and s
Thinking (0),
Hungry (1),
Eating (2) Normal int array

state

semaphore array, initialized to 0

s 0 0 0 0 0 0 0 0

• State takes care of acquiring the fork

• s stops a philosopher from eating when fork is not available
 Dining Philosophers Problem
Final solution

...
 Dining Philosophers Problem
Final solution
...

...
 Dining Philosophers Problem
... Final solution
The Sleeping Barber Problem
Barber sleeps on “Customer”
Customer sleeps on “Barber”

For Barber: Checking the

waiting room and calling
the customer makes the
critical section

For customer:
Checking the waiting
room and informing
the barber makes its
critical section
Deadlock
 The Deadlock Problem
• A set of blocked processes each holding a resource and
waiting to acquire a resource held by another process in
the set

• Example
– System has 2 disk drives
– P1 and P2 each hold one disk drive and each needs another one

• Example
– semaphores A and B, initialized to 1
P0 P1
wait (A); wait (B);
wait(B) wait(A)
 Introduction To Deadlocks

Deadlock can be defined formally as follows:

A set of processes is deadlocked if each process

in the set is waiting for an event that only
another process in the set can cause.
 System Model
• Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices

• Each resource type Ri has Wi instances.

• Each process requests for an instance of a

resource type

• Each process utilizes a resource as follows:

– request
– use
– release
 Deadlock: necessary conditions
Deadlock can arise if four conditions hold simultaneously.

• Mutual exclusion: only one process at a time can use a

resource
• Hold and wait: a process holding at least one resource is
waiting to acquire additional resources held by other
processes
• No preemption: a resource can be released only
voluntarily by the process holding it, after that process has
completed its task
• Circular wait: there exists a set {P0, P1, …, Pn} of waiting
processes such that P0 is waiting for a resource that is held
by P1, P1 is waiting for a resource that is held by
P2, …, Pn–1 is waiting for a resource that is held by Pn, and
Pn is waiting for a resource that is held by P0.
 Resource-Allocation Graph
A set of vertices V and a set of edges E.

• V is partitioned into two types:

– P = {P1, P2, …, Pn}, the set consisting of all
the processes in the system

– R = {R1, R2, …, Rm}, the set consisting of all

resource types in the system
• request edge – directed edge Pi → Rj
• assignment edge – directed edge Rj → Pi
 Resource-Allocation Graph (Cont.)

• Process

• Resource Type with 4 instances

• Pi requests instance of Rj Pi
Rj

• Pi is holding an instance of Rj Pi
Rj
Example of a Resource Allocation Graph

No cycle; No
deadlock
 One Resource of Each Type
• Figure 6-5. (a) A resource graph. (b) A cycle
extracted from (a).

Contains Cycle; Deadlock

Resource Allocation Graph With A Deadlock

P3 requests R2
 Graph With A Cycle But No Deadlock

P1->R1->P3->R2->P1
• If the resource allocation graph does not have a
cycle
• System is not in a deadlocked state

• If there is a cycle
• May or may not be in a deadlocked state
 Deadlock Modeling
• Figure 6-4. An example of how deadlock
occurs
and how it can be avoided.
 Deadlock Modeling
• Figure 6-4. An example of how deadlock
occurs
and how it can be avoided.

Deadlock
 Deadlock Modeling
• Figure 6-4. An example of how deadlock
occurs
and how it can be avoided.

Suspend process B
 Deadlock Handling
Strategies for dealing with deadlocks:
1.Detection and recovery. Let deadlocks occur,
detect them, take action.
2.Dynamic avoidance by careful resource
allocation.
3.Prevention, by structurally negating one of the
four required conditions.
4. Just ignore the problem.
Tutorials
The Sleeping Barber Problem
 Challenges
• Actions taken by barber and customer takes unknown amount of time
(checking waiting room, entering shop, taking waiting room chair)
• Scenario 1
– Customer arrives, observe that barber busy
– Goes to waiting room
– While he is on the way, barber finishes the haircut
– Barber checks the waiting room
– Since no one there, Barber sleeps
– The customer reaches the waiting room and waits forever
• Scenario 2
– Two customer arrives at the same time
– Barber is busy
– Both customers try to occupy the same chair!
 Barber sleeps on “Customer”
Customer sleeps on “Barber”

One semaphore:
customer No customer: Barber falls asleep
“I have arrived; waiting for
your service”
Customer
Barber

Barber wakes up, if sleeping

One semaphore:
barber Customer acquires the Barber for service
“I am ready to give service
to the next customer”
Barber Customer

Customer waits if Barber busy

The Sleeping Barber Problem
Semaphore Barber: Used to
call a waiting customer.
Barber=1: Barber is ready
to cut hair and a customer
is ready (to get service) too!
Barber=0: customer
occupies barber or waits

Semaphore customer:
Customer informs barber
that “I have arrived; waiting
for your service”
Mutex: Ensures that only
one of the participants
can change state at once
The Sleeping Barber Problem
Barber sleeps on “Customer”
Customer sleeps on “Barber”

For Barber: Checking the

waiting room and calling
the customer makes the
critical section

For customer:
Checking the waiting
room and informing
the barber makes its
critical section
 Problem 1
We want to use semaphores to implement a shared critical
section (CS) among three processes T1, T2, and T3. We want to
enforce the execution in the CS in this order: First T2 must execute
in the CS. When it finishes, T1 will then be allowed to enter the
CS; and when it finishes T3 will then be allowed to enter the CS;
when T3 finishes then T2 will be allowed to enter the CS, and so
on, (T2, T1, T3, T2, T1, T3,…).

Write the synchronization solution using a minimum number of

binary semaphores and you are allowed to assume the initial
value for semaphore variables.
 Problem 1

S1=1, S2=0, S3=0

 Problem 2
Three concurrent processes X, Y, and Z execute three different code segments that
access and update certain shared variables.
Process X executes the P operation (i.e., wait) on semaphores a, b and c;
process Y executes the P operation on semaphores b, c and d;
process Z executes the P operation on semaphores c, d, and a before entering the
respective code segments.
After completing the execution of its code segment, each process invokes the V
operation (i.e., signal) on its three semaphores.
All semaphores are binary semaphores initialized to one.
Which one of the following represents a deadlock-free order of invoking the P
operations by the processes?

(A) X: P(a)P(b)P(c) Y: P(b)P(c)P(d) Z: P(c)P(d)P(a)

(B) X: P(b)P(a)P(c) Y: P(b)P(c)P(d) Z: P(a)P(c)P(d)
(C) X: P(b)P(a)P(c) Y: P(c)P(b)P(d) Z: P(a)P(c)P(d)
(D) X: P(a)P(b)P(c) Y: P(c)P(b)P(d) Z: P(c)P(d)P(a)
 Problem 3
• The following two functions P1 and P2 that share a variable B with an
initial value of 2 execute concurrently.
P1()
{
C = B – 1;
B = 2*C;
}

P2()
{
D = 2 * B;
B = D - 1;
}
The number of distinct values that B can possibly take after the execution
 Problem 4

Consider the reader-writer problem with designated readers. There are n reader
processes, where n is known beforehand. There are one or more writer processes.
Items are stored in a buffer. Every item is written by a writer and is designated for a
particular reader.
 Deadlock Detection

• Allow system to enter deadlock state

• Detection algorithm

• Recovery scheme
Single Instance of Each Resource Type

• In resource graph
– Pi → R and R → Pj

• Maintain wait-for graph

– Nodes are processes
– Pi → Pj if Pi is waiting for Pj

• Periodically invoke an algorithm that searches for a

cycle in the graph.

• If there is a cycle, there exists a deadlock

 Resource-Allocation Graph and
Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

 Several Instances of a Resource Type
Let n = number of processes, and m = number of resources types.

• Available: A vector of length m indicates the number of

available resources of each type.
R0 R1 R2 R3

• Allocation: An n x m matrix defines the number of

resources of each type currently allocated to each process.

P0 P0
P1 Allocation P1 Request
matrix matrix
P2 P2
R0 R1 R2 R3 R0 R1 R2 R3

• Request: An n x m matrix indicates the current request of

each process. If Request [i][j] = k, then process Pi is
requesting k more instances of resource type Rj.
 Several Instances of a Resource Type
Let n = number of processes, and m = number of resources types.

• Figure 6-6. The four data structures needed

by the deadlock detection algorithm.
 Detection Algorithm
• Define a relation  over two vectors

• X and Y are two vectors of length n

• We say X  Y
Iff X[i] Y[i] for all i=1, 2, …, n
 Detection Algorithm
1. Let Work and Finish be vectors of length m and
n, respectively
Initialize:
(a) Work = Available
(b)For i = 1,2, …, n, if Allocationi  0, then
Finish[i] = false; otherwise, Finish[i] = true

2. Find an index i such that both:

(a) Finish[i] == false
(b)Requesti  Work

If no such i exists, go to step 4

 Detection Algorithm (Cont.)
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish[i] == false, for some i, 1  i  n, then the system is in
deadlock state. Moreover, if Finish[i] == false, then Pi is
deadlocked
 Example of Detection Algorithm
• Five processes P0 through P4;
• three resource types
A (7 instances), B (2 instances), and C (6 instances)

• Snapshot at time T0:

Allocation Request Available
ABC ABC ABC
P0 010 000 000
P1 200 202
P2 303 000
P3 211 100
P4 002 002

• Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i
 Example (Cont.)
• P2 requests an additional instance of type C
Request
ABC
P0 0 0 0
P1 2 0 2
P2 0 0 1
P3 1 0 0
P4 0 0 2
• State of system?
– Can reclaim resources held by process P0, but insufficient
resources to fulfill other processes; requests
– Deadlock exists, consisting of processes P1, P2, P3, and P4
Home work

Available
 Detection-Algorithm Usage
• When, and how often, to invoke depends on:
– How often a deadlock is likely to occur?
– How many processes will be affected by deadlock?
• If deadlock frequent
– Invoke detection algo frequently

• Invoke after each (waiting) resource request

– Huge overhead
• CPU utilization drops
 Recovery from Deadlock:
Process Termination
• Abort all deadlocked processes
– Expensive

• Abort one process at a time until the deadlock cycle is

eliminated
– Overhead=> invoke detection algo

• In which order should we choose to abort?

– Priority of the process
– How long process has computed
– Resources the process has used
– Resources process needs to complete
– How many processes will need to be terminated
– Is process interactive or batch?
 Recovery from Deadlock:
Resource Preemption

• Selecting a victim – minimize cost

– (# of resources holding, duration)

• Rollback – return to some safe state, restart

process from that state

• Starvation – same process may always be

picked as victim, include number of rollback in
cost factor
 Deadlock Avoidance
Requires that the system has some additional a priori
information available
• Simplest and most useful model requires that each
process declare the maximum number of resources
of each type that it may need

• The deadlock-avoidance algorithm dynamically

examines the resource-allocation state to ensure
that there can never be a circular-wait condition

• Resource-allocation state is defined by the number

of available and allocated resources, and the
maximum demands of the processes
Safe State
 Safe State
• When a process requests an available resource, system must
decide if immediate allocation leaves the system in a safe state

• System is in safe state if there exists a sequence <P1, P2, …, Pn>

of ALL the processes in the systems
– such that for each Pi, the resources that Pi can still request can be
satisfied by currently available resources + resources held by all the
Pj, with j < i

• That is:
– If Pi resource needs are not immediately available, then Pi can wait
until all Pj have finished
– When Pj is finished, Pi can obtain needed resources, execute, return
allocated resources, and terminate
– When Pi terminates, Pi +1 can obtain its needed resources, and so on
 Basic Facts
• If a system is in safe state  no deadlocks

• If a system is in unsafe state  possibility

of deadlock

• Avoidance  ensure that a system will

never enter an unsafe state.
Safe, Unsafe, Deadlock State
Three processes P0, P1, P2

Resource R=12
State at time t0

Maximum need Current allocation

P0 10 5
P1 4 2
P2 9 2

Free resource = 3

Safe sequence <P1, P0, P2> Safe state

State at time t1
Allocate one resource to P2
 Avoidance algorithms

• Single instance of a resource type

– Use a resource-allocation graph

• Multiple instances of a resource type

– Use the banker’s algorithm
 Resource-Allocation Graph Scheme
• Claim edge Pi → Rj indicated that process Pj may
request resource Rj; represented by a dashed line

• Claim edge converts to request edge when a process

requests a resource

• Request edge converted to an assignment edge when

the resource is allocated to the process

• When a resource is released by a process, assignment

edge reconverts to a claim edge

• Resources must be claimed a priori in the system

 Resource-Allocation Graph
Request edge
Assignment edge

Claim edge
 Resource-Allocation Graph
Algorithm
• Suppose that process Pi requests a resource Rj

• The request can be granted only if converting

the request edge to an assignment edge does
not result in the formation of a cycle in the
resource allocation graph

• If no cycle
– Safe state
 Unsafe State In Resource-Allocation Graph

Suppose that process P2 requests a resource

R2
 Banker’s Algorithm
• Multiple instances

• Each process must a priori claim maximum use

• When a process requests a set of resources

– System decides whether the allocation is safe

• When a process requests a resource – not safe?

– it may have to wait

• When a process gets all its resources it must return

them in a finite amount of time
 Data Structures for the Banker’s Algorithm

Let n = number of processes, and m = number of resources types.

• Available: Vector of length m. If available [j] = k, there

are k instances of resource type Rj available
• Max: n x m matrix. If Max [i,j] = k, then process Pi may
request at most k instances of resource type Rj
• Allocation: n x m matrix. If Allocation[i,j] = k then Pi is
currently allocated k instances of Rj
• Need: n x m matrix. If Need[i,j] = k, then Pi may need k
more instances of Rj to complete its task
Need [i,j] = Max[i,j] – Allocation [i,j]
 Several Instances of a Resource Type
Let n = number of processes, and m = number of resources types.

• Available: A vector of length m indicates the number of

available resources of each type.
R0 R1 R2 R3

• Allocation: An n x m matrix defines the number of

resources of each type currently allocated to each process.

P0 P0
P1 Allocation P1 Max
matrix matrix
P2 P2
R0 R1 R2 R3 R0 R1 R2 R3
 Deadlock avoidance :
Flow chart for Pi
Pi requests Take decision
resources (safety algorithm)
Requesti[] yes
Permanent
Provisionally
State Safe allocation of
allocate
state? resource
resources
New state
Temporary No
state (Request
algorithm)

Restore the old state

 Safety Algorithm
1. Let Work and Finish be vectors of length m
and n, respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, …, n- 1
2. Find an i such that both:
(a) Finish [i] = false
(b) Needi  Work
If no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish [i] == true for all i, then the system
is in a safe state
Resource-Request Algorithm for Process Pi
Request = request vector for process Pi.
If Requesti [j] = k then process Pi wants k instances of
resource type Rj
1. If Requesti  Needi go to step 2. Otherwise, raise error
condition, since process has exceeded its maximum
claim
2. If Requesti  Available, go to step 3. Otherwise Pi must
wait, since resources are not available
3. Pretend to allocate requested resources to Pi by
modifying the state as follows:
Available = Available – Requesti;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;

If safe  the resources are allocated to Pi

If unsafe  Pi must wait, and the old resource-allocation state
is restored
 Example of Banker’s Algorithm
• 5 processes P0 through P4;
3 resource types:
A (10 instances), B (5instances), and C (7
instances)
Snapshot at time T0:
Allocation Max Available
ABC ABC ABC
P0 0 1 0 753 332
P1 2 0 0 322
P2 3 0 2 902
P3 2 1 1 222
P4 0 0 2 433
 Example (Cont.)
• The content of the matrix Need is defined to be Max – Allocation

Need
ABC
P0 743
P1 122
P2 600
P3 011
P4 431

Allocation Max Available

ABC ABC ABC
P0 010 753 332
P1 200 322
P2 302 902
P3 211 222
P4 002 433

• The system is in a safe state since the sequence < P1, P3, P4, P2, P0> satisfies safety criteria
 Example (Cont.)
• The content of the matrix Need is defined to be Max – Allocation

Need
ABC
P0 743
P1 122
P2 600
P3 011
P4 431

• The system is in a safe state since the sequence < P1, P3, P4, P2, P0>
satisfies safety criteria
 Example: P1 Request (1,0,2)
• Check that Request  Available (that is, (1,0,2)  (3,3,2)
 true
Allocation Need Available
ABC ABC ABC
P0 0 1 0 743 230
P1 302 020
P2 3 0 2 600
P3 2 1 1 011
P4 0 0 2 431
• Executing safety algorithm shows that sequence < P1,
P3, P4, P0, P2> satisfies safety requirement
• Can request for (3,3,0) by P4 be granted?
• Can request for (0,2,0) by P0 be granted?
 Deadlock Handling
Strategies for dealing with deadlocks:
1.Detection and recovery. Let deadlocks occur,
detect them, take action.
2.Dynamic avoidance by careful resource
allocation.
3.Prevention, by structurally negating one of the
four required conditions.
4. Just ignore the problem.
 Deadlock Prevention
Restrain the ways request can be made

• Mutual Exclusion – not required for sharable

resources; must hold for nonsharable resources
– Read only file

• Hold and Wait – must guarantee that whenever a

process requests a resource, it does not hold any
other resources
– Require process to request and be allocated all its
resources before it begins execution,
– Allow process to request resources only when the
process has none
• Release all the current resource and then try to acquire
– Low resource utilization; starvation possible
 Deadlock Prevention (Cont.)
• No Preemption –
– If a process that is holding some resources,
– Requests another resource that cannot be
immediately allocated to it
• Resources were allocated to some waiting process
– Preempt the desired resource from waiting process
– Allocate to current process
– Cpu Registers
• Circular Wait – Impose a total ordering of all
resource types
– Require that each process requests resources in an
increasing order of enumeration
• Let R={R1, R2,……,Rm} set of resource type
• We assign unique integer with each type
• One to one function F:R→N
F(tape drive)=1
F(disk)=5
F(printer)=12
• Protocol: Each process can request resource only in an
increasing order.
• Initially request Ri, after that, it can request Rj
– If and only if F(Rj)>F(Ri)
• Currently holding Rj; Want to request Ri.
• Must have released Rj
 F(R0) < F(R1)

R0 R1 R(n-1) R(n)
Rn

P0 P1 P(n-1) Pn

F(R0) < F(R1) < F(R2) <…………………< F(Rn) < F(R0)

 Problem 1
A system is having 3 user processes each
requiring max 2 units of resource R.
What is the minimum number of units of R such
that no deadlock will occur?
Problem 2
 Problem 3
Q1: A single processor system has three resource types X, Y, and Z, which are shared by three processes. There are 5 units of
each resource type.
Allocation Request
X Y Z X Y Z

P0 1 2 1 P0 1 0 3

P1 2 0 1 P1 0 1 2

P2 2 2 1 P2 1 2 0

(i) Is the system in a safe state? What is the safe sequence?

(ii) What will happen if process P1 requests two additional instances of resource type C?
.
 Answer:

(i) According to the question-

Total = [ X Y Z ] = [ 5 5 5 ] , Total _Allocation = [ X Y Z ] = [5 4 3]
Now, Available = Total – Total_Allocation = [ 5 5 5 ] – [5 4 3] = [ 0 1 2 ]

• Step: With the instances available currently, only the requirement of process P1 can be satisfied. So, process P1 is allocated
the requested resources. It completes its execution and then frees up the instances of resources held by it.
(Then, Available = [ 0 1 2 ] + [ 2 0 1] = [ 2 1 3 ]

By repeating the above step, we will get the following

--→ P0, Available = [3 3 4]

-→ P2, Available = [5 5 5]
-→ There exists a safe sequence P1, P0, P2 in which all the processes can be executed.

(ii)New_Request = P1 [0 0 2], so Now, available becomes [0 1 0],