MODULE 2: MULTI-THREADED PROGRAMMING

PROCESS SCHEDULING
PROCESS SYNCHRONIZATION

2.1. Multi-Threaded Programming

2.1.1. Motivation
2.1.2. Benefits
2.2. Multi-Threading Models
2.2.1. Many-to-One Model
2.2.2. One-to-One Model
2.2.3. Many-to-Many Model
2.3. Thread Libraries
2.3.1. Pthreads
2.3.2. Java Threads
2.4. Threading Issues
2.4.1. fork() and exec() System-calls
2.4.2. Thread Cancellation
2.4.3. Signal Handling
2.4.4. Thread Pools
2.5. Basic Concepts
2.5.1. CPU-I/0 Burst Cycle
2.5.2. CPU Scheduler
2.5.3. CPU Scheduling
2.5.4. Dispatcher
2.6. Scheduling Criteria
2.7. Scheduling Algorithms
2.7.1. FCFS Scheduling
2.7.2. SJF Scheduling
2.7.3. Priority Scheduling
2.7.4. Round Robin Scheduling
2.7.5. Multilevel Queue Scheduling
2.7.6. Multilevel Feedback Queue Scheduling
2.8. Multiple-Processor Scheduling
2.8.1. Processor Affinity
2.8.2. Load Balancing
2.8.3. Symmetric Multithreading
2.9. Thread Scheduling
2.9.1. Contention Scope
2.9.2. Pthread Scheduling
2.10. Synchronization
2.11. The Critical-Section Problem
2.12. Peterson‘s Solution
2.13. Synchronization Hardware
2.13.1. Hardware based Solution for Critical-section Problem
2.13.2. Hardware instructions for solving critical-section problem
2.13.2.1. TestAndSet()
2.13.2.2. TestAndSet with Mutual Exclusion
2.13.2.3. Swap()
2.13.2.4. Bounded waiting Mutual Exclusion with TestAndSet()

2.14. Semaphores
2.14.1. Semaphore Usage
2.14.2. Semaphore Implementation
2.14.3. Deadlocks & Starvation
2.15. Classic Problems of Synchronization
2.15.1. Bounded-Buffer Problem
2.15.2. Readers-Writers Problem
2.15.3. Dining-Philosophers Problem
2.16. Monitors
2.16.1. Monitors Usage
2.16.2. Dining-Philosophers Solution Using Monitors
2.16.3. Implementing a Monitor using Semaphores
2.16.4. Resuming Processes within a Monitor
 MODULE 2: MULTI-THREADED PROGRAMMING

Multi-Threaded Programming
• A thread is a basic unit of CPU utilization.
• It consists of
→ thread ID
→ PC
→ register-set and
→ stack.
• It shares with other threads belonging to the same process its code-section & data-section.
• A traditional (or heavy weight) process has a single thread of control.
• If a process has multiple threads of control, it can perform more than one task at a time. Such a
process is called multi-threaded process (Figure 2.1).

Figure 2.1 Single-threaded and multithreaded processes

Motivation
1) The software-packages that run on modern PCs are multithreaded.
An application is implemented as a separate process with several threads of control.
For ex: A word processor may have
→ first thread for displaying graphics
→ second thread for responding to keystrokes and
→ third thread for performing grammar checking.
2) In some situations, a single application may be required to perform several similar tasks.
For ex: A web-server may create a separate thread for each client request.
This allows the server to service several concurrent requests.
3) RPC servers are multithreaded.
When a server receives a message, it services the message using a separate thread.
This allows the server to service several concurrent requests.
4) Most OS kernels are multithreaded;
Several threads operate in kernel, and each thread performs a specific task, such as
→ managing devices or
→ interrupt handling.
 Benefits
1) Responsiveness
• A program may be allowed to continue running even if part of it is blocked.
Thus, increasing responsiveness to the user.
2) Resource Sharing
• By default, threads share the memory (and resources) of the process to which they belong.
Thus, an application is allowed to have several different threads of activity within the same
address-space.
3) Economy
• Allocating memory and resources for process-creation is costly.
Thus, it is more economical to create and context-switch threads.
4) Utilization of Multiprocessor Architectures
• In a multiprocessor architecture, threads may be running in parallel on different processors.
Thus, parallelism will be increased.
 Multi-Threading Models
• Support for threads may be provided at either
1) The user level, for user threads or
2) By the kernel, for kernel threads.
• User-threads are supported above the kernel and are managed without kernel support.
Kernel-threads are supported and managed directly by the OS.
• Three ways of establishing relationship between user-threads & kernel-threads:
1) Many-to-one model
2) One-to-one model and
3) Many-to-many model.

Many-to-One Model
• Many user-level threads are mapped to one kernel thread (Figure 2.2).
• Advantage:
1) Thread management is done by the thread library in user space, so it is efficient.
• Disadvantages:
1) The entire process will block if a thread makes a blocking system-call.
2) Multiple threads are unable to run in parallel on multiprocessors.
• For example:
→ Solaris green threads
→ GNU portable threads.

Figure 2.2 Many-to-one model Figure 2.3 One-to-one model

One-to-One Model
• Each user thread is mapped to a kernel thread (Figure 2.3).
• Advantages:
1) It provides more concurrency by allowing another thread to run when a thread makes a
blocking system-call.
2) Multiple threads can run in parallel on multiprocessors.
• Disadvantage:
1) Creating a user thread requires creating the corresponding kernel thread.
• For example:
→ Windows NT/XP/2000
→ Linux
 Many-to-Many Model
• Many user-level threads are multiplexed to a smaller number of kernel threads (Figure 2.4).
• Advantages:
1) Developers can create as many user threads as necessary
2) The kernel threads can run in parallel on a multiprocessor.
3) When a thread performs a blocking system-call, kernel can schedule another thread for
execution.
Two Level Model
• A variation on the many-to-many model is the two level-model (Figure 2.5).
• Similar to M:M, except that it allows a user thread to be bound to kernel thread.
• For example:
→ HP-UX
→ Tru64 UNIX

Figure 2.4 Many-to-many model Figure 2.5 Two-level model

.
 Thread Libraries
• It provides the programmer with an API for the creation and management of threads.
• Two ways of implementation:
1) First Approach
 Provides a library entirely in user space with no kernel support.
 All code and data structures for the library exist in the user space.
2) Second Approach
 Implements a kernel-level library supported directly by the OS.
 Code and data structures for the library exist in kernel space.
• Three main thread libraries: 1) POSIX Pthreads
2) Win32 and
3) Java.

Pthreads
• This is a POSIX standard API for thread creation and synchronization.
• This is a specification for thread-behavior, not an implementation.
• OS designers may implement the specification in any way they wish.
• Commonly used in: UNIX and Solaris.

Java Threads
• Threads are the basic model of program-execution in
→ Java program and
→ Java language.
• The API provides a rich set of features for the creation and management of threads.
• All Java programs comprise at least a single thread of control.
• Two techniques for creating threads:
1) Create a new class that is derived from the Thread class and override its run() method.
2) Define a class that implements the Runnable interface. The Runnable interface is defined as
follows:
 Threading Issues
fork() and exec() System-calls
• fork() is used to create a separate, duplicate process.
• If one thread in a program calls fork(), then
1) Some systems duplicates all threads and
2) Other systems duplicate only the thread that invoked the fork().
• If a thread invokes the exec(), the program specified in the parameter to exec() will replace the
entire process including all threads.

Thread Cancellation
• This is the task of terminating a thread before it has completed.
• Target thread is the thread that is to be canceled
• Thread cancellation occurs in two different cases:
1) Asynchronous cancellation: One thread immediately terminates the target thread.
2) Deferred cancellation: The target thread periodically checks whether it should be terminated.

Signal Handling
• In UNIX, a signal is used to notify a process that a particular event has occurred.
• All signals follow this pattern:
1) A signal is generated by the occurrence of a certain event.
2) A generated signal is delivered to a process.
3) Once delivered, the signal must be handled.
• A signal handler is used to process signals.
• A signal may be received either synchronously or asynchronously, depending on the source.
1) Synchronous signals
 Delivered to the same process that performed the operation causing the signal.
 E.g. illegal memory access and division by 0.
2) Asynchronous signals
 Generated by an event external to a running process.
 E.g. user terminating a process with specific keystrokes <ctrl><c>.
• Every signal can be handled by one of two possible handlers:
1) A Default Signal Handler
 Run by the kernel when handling the signal.
2) A User-defined Signal Handler
 Overrides the default signal handler.
• In single-threaded programs, delivering signals is simple.
In multithreaded programs, delivering signals is more complex. Then, the following options exist:
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
• The basic idea is to
→ create a no. of threads at process-startup and
→ place the threads into a pool (where they sit and wait for work).
• Procedure:
1) When a server receives a request, it awakens a thread from the pool.
2) If any thread is available, the request is passed to it for service.
3) Once the service is completed, the thread returns to the pool.
• Advantages:
1) Servicing a request with an existing thread is usually faster than waiting to create a thread.
2) The pool limits the no. of threads that exist at any one point.
• No. of threads in the pool can be based on factors such as
→ no. of CPUs
→ amount of memory and
→ expected no. of concurrent client-requests.
 MODULE 2 (CONT.): PROCESS SCHEDULING

Basic Concepts
• In a single-processor system,
→ only one process may run at a time.
→ other processes must wait until the CPU is rescheduled.
• Objective of multiprogramming:
→ to have some process running at all times, in order to maximize CPU utilization.

CPU-I/0 Burst Cycle

• Process execution consists of a cycle of
→ CPU execution and
→ I/O wait (Figure 2.6 & 2.7).
• Process execution begins with a CPU burst, followed by an I/O burst, then another CPU burst, etc…
• Finally, a CPU burst ends with a request to terminate execution.
• An I/O-bound program typically has many short CPU bursts.
A CPU-bound program might have a few long CPU bursts.

Figure 2.6 Alternating sequence of CPU and I/O bursts

Figure 2.7 Histogram of CPU-burst durations

 CPU Scheduler
• This scheduler
→ selects a waiting-process from the ready-queue and
→ allocates CPU to the waiting-process.
• The ready-queue could be a FIFO, priority queue, tree and list.
• The records in the queues are generally process control blocks (PCBs) of the processes.

CPU Scheduling
• Four situations under which CPU scheduling decisions take place:
1) When a process switches from the running state to the waiting state.
For ex; I/O request.
2) When a process switches from the running state to the ready state.
For ex: when an interrupt occurs.
3) When a process switches from the waiting state to the ready state.
For ex: completion of I/O.
4) When a process terminates.
• Scheduling under 1 and 4 is non-preemptive.
Scheduling under 2 and 3 is preemptive.
Non Preemptive 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.
Preemptive Scheduling
• This is driven by the idea of prioritized computation.
• Processes that are runnable may be temporarily suspended
• Disadvantages:
1) Incurs a cost associated with access to shared-data.
2) Affects the design of the OS kernel.

Dispatcher
• It gives control of the CPU to the process selected by the short-term scheduler.
• The function involves:
1) Switching context
2) Switching to user mode &
3) Jumping to the proper location in the user program to restart that program.
• It should be as fast as possible, since it is invoked during every process switch.
• Dispatch latency means the time taken by the dispatcher to
→ stop one process and
→ start another running.
 Scheduling Criteria
• Different CPU-scheduling algorithms
→ have different properties and
→ may favor one class of processes over another.
• Criteria to compare CPU-scheduling algorithms:
1) CPU Utilization
 We must keep the CPU as busy as possible.
 In a real system, it ranges from 40% to 90%.
2) Throughput
 Number of processes completed per time unit.
 For long processes, throughput may be 1 process per hour;
For short transactions, throughput might be 10 processes per second.
3) Turnaround Time
 The interval from the time of submission of a process to the time of completion.
 Turnaround time is the sum of the periods spent
→ waiting to get into memory
→ waiting in the ready-queue
→ executing on the CPU and
→ doing I/O.
4) Waiting Time
 The amount of time that a process spends waiting in the ready-queue.
5) Response Time
 The time from the submission of a request until the first response is produced.
 The time is generally limited by the speed of the output device.
• We want
→ to maximize CPU utilization and throughput and
→ to minimize turnaround time, waiting time, and response time.
 Scheduling Algorithms
• CPU scheduling deals with the problem of deciding which of the processes in the ready-queue is to be
allocated the CPU.
• Following are some scheduling algorithms:
1) FCFS scheduling (First Come First Served)
2) Round Robin scheduling
3) SJF scheduling (Shortest Job First)
4) SRT scheduling
5) Priority scheduling
6) Multilevel Queue scheduling and
7) Multilevel Feedback Queue scheduling

FCFS Scheduling
• The process that requests the CPU first is allocated the CPU first.
• The implementation is easily done using a FIFO queue.
• Procedure:
1) When a process enters the ready-queue, its PCB is linked onto the tail of the queue.
2) When the CPU is free, the CPU is allocated to the process at the queue‘s head.
3) The running process is then removed from the queue.
• Advantage:
1) Code is simple to write & understand.
• Disadvantages:
1) Convoy effect: All other processes wait for one big process to get off the CPU.
2) Non-preemptive (a process keeps the CPU until it releases it).
3) Not good for time-sharing systems.
4) The average waiting time is generally not minimal.
• Example: Suppose that the processes arrive in the order P1, P2, P3.

• The Gantt Chart for the schedule is as follows:

• Waiting time for P1 = 0; P2 = 24; P3 = 27

Average waiting time: (0 + 24 + 27)/3 = 17

• Suppose that the processes arrive in the order P2, P3, P1.
• The Gantt chart for the schedule is as follows:

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

Average waiting time: (6 + 0 + 3)/3 = 3
 SJF Scheduling
• The CPU is assigned to the process that has the smallest next CPU burst.
• If two processes have the same length CPU burst, FCFS scheduling is used to break the tie.
• For long-term scheduling in a batch system, we can use the process time limit specified by the user,
as the ‗length‘
• SJF can't be implemented at the level of short-term scheduling, because there is no way to know the
length of the next CPU burst
• Advantage:
1) The SJF is optimal, i.e. it gives the minimum average waiting time for a given set of
processes.
• Disadvantage:
1) Determining the length of the next CPU burst.
• SJF algorithm may be either 1) non-preemptive or
2) preemptive.
1) Non preemptive SJF
 The current process is allowed to finish its CPU burst.
2) Preemptive SJF
 If the new process has a shorter next CPU burst than what is left of the executing process,
that process is preempted.
 It is also known as SRTF scheduling (Shortest-Remaining-Time-First).
• Example (for non-preemptive SJF): Consider the following set of processes, with the length of the
CPU-burst time given in milliseconds.

• For non-preemptive SJF, the Gantt Chart is as follows:

• Waiting time for P1 = 3; P2 = 16; P3 = 9; P4=0

Average waiting time: (3 + 16 + 9 + 0)/4 = 7
• Example (preemptive SJF): Consider the following set of processes, with the length of the CPU-burst
time given in milliseconds.

• For preemptive SJF, the Gantt Chart is as follows:

• The average waiting time is ((10 - 1) + (1 - 1) + (17 - 2) + (5 - 3))/4 = 26/4 = 6.5.

 Priority Scheduling
• A priority is associated with each process.
• The CPU is allocated to the process with the highest priority.
• Equal-priority processes are scheduled in FCFS order.
• Priorities can be defined either internally or externally.
1) Internally-defined priorities.
 Use some measurable quantity to compute the priority of a process.
 For example: time limits, memory requirements, no. of open files.
2) Externally-defined priorities.
 Set by criteria that are external to the OS
 For example:
→ importance of the process
→ political factors
• Priority scheduling can be either preemptive or nonpreemptive.
1) Preemptive
 The CPU is preempted if the priority of the newly arrived process is higher than the priority of
the currently running process.
2) Non Preemptive
 The new process is put at the head of the ready-queue
• Advantage:
1) Higher priority processes can be executed first.
• Disadvantage:
1) Indefinite blocking, where low-priority processes are left waiting indefinitely for CPU.
Solution: Aging is a technique of increasing priority of processes that wait in system for a long time.
• Example: Consider the following set of processes, assumed to have arrived at time 0, in the order PI,
P2, ..., P5, with the length of the CPU-burst time given in milliseconds.

• The Gantt chart for the schedule is as follows:

• The average waiting time is 8.2 milliseconds.

 Round Robin Scheduling
• Designed especially for timesharing systems.
• It is similar to FCFS scheduling, but with preemption.
• A small unit of time is called a time quantum (or time slice).
• Time quantum is ranges from 10 to 100 ms.
• The ready-queue is treated as a circular queue.
• The CPU scheduler
→ goes around the ready-queue and
→ allocates the CPU to each process for a time interval of up to 1 time quantum.
• To implement:
The ready-queue is kept as a FIFO queue of processes
• CPU scheduler
1) Picks the first process from the ready-queue.
2) Sets a timer to interrupt after 1 time quantum and
3) Dispatches the process.
• One of two things will then happen.
1) The process may have a CPU burst of less than 1 time quantum.
In this case, the process itself will release the CPU voluntarily.
2) If 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.
The process will be put at the tail of the ready-queue.
• Advantage:
1) Higher average turnaround than SJF.
• Disadvantage:
1) Better response time than SJF.
• Example: Consider the following set of processes that arrive at time 0, with the length of the CPU-
burst time given in milliseconds.

• The Gantt chart for the schedule is as follows:

• The average waiting time is 17/3 = 5.66 milliseconds.

• The RR scheduling algorithm is preemptive.
No process is allocated the CPU for more than 1 time quantum in a row. If a process' CPU burst
exceeds 1 time quantum, that process is preempted and is put back in the ready-queue..
• The performance of algorithm depends heavily on the size of the time quantum (Figure 2.8 & 2.9).
1) If time quantum=very large, RR policy is the same as the FCFS policy.
2) If time quantum=very small, RR approach appears to the users as though each of n
processes has its own processor running at l/n the speed of the real processor.
• In software, we need to consider the effect of context switching on the performance of RR scheduling
1) Larger the time quantum for a specific process time, less time is spend on context switching.
2) The smaller the time quantum, more overhead is added for the purpose of context-switching.
Figure 2.8 How a smaller time quantum increases context switches

Figure 2.9 How turnaround time varies with the time quantum
 Multilevel Queue Scheduling
• Useful for situations in which processes are easily classified into different groups.
• For example, a common division is made between
→ foreground (or interactive) processes and
→ background (or batch) processes.
• The ready-queue is partitioned into several separate queues (Figure 2.10).
• The processes are permanently assigned to one queue based on some property like
→ memory size
→ process priority or
→ process type.
• Each queue has its own scheduling algorithm.
For example, separate queues might be used for foreground and background processes.

Figure 2.10 Multilevel queue scheduling

• There must be scheduling among the queues, which is commonly implemented as fixed-priority
preemptive scheduling.
For example, the foreground queue may have absolute priority over the background queue.
• 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 Scheduling
• A process may move between queues (Figure 2.11).
• The basic idea:
Separate processes according to the features of their CPU bursts. For example
1) 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.
2) If a process waits too long in a lower-priority queue, it may be moved to a higher-
priority queue
¤ This form of aging prevents starvation.

Figure 2.11 Multilevel feedback queues.

• In general, a multilevel feedback queue scheduler is defined by the following parameters:

1) The number of queues.
2) The scheduling algorithm for each queue.
3) The method used to determine when to upgrade a process to a higher priority queue.
4) The method used to determine when to demote a process to a lower priority queue.
5) The method used to determine which queue a process will enter when that process needs
service.
 Multiple Processor Scheduling
• If multiple CPUs are available, the scheduling problem becomes more complex.
• Two approaches:
1) Asymmetric Multiprocessing
 The basic idea is:
i) A master server is a single processor responsible for all scheduling decisions, I/O
processing and other system activities.
ii) The other processors execute only user code.
 Advantage:
i) This is simple because only one processor accesses the system data structures,
reducing the need for data sharing.
2) Symmetric Multiprocessing
 The basic idea is:
i) Each processor is self-scheduling.
ii) To do scheduling, the scheduler for each processor
i. Examines the ready-queue and
ii. Selects a process to execute.
 Restriction: We must ensure that two processors do not choose the same process and that
processes are not lost from the queue.

Processor Affinity
• In SMP systems,
1) Migration of processes from one processor to another are avoided and
2) Instead processes are kept running on same processor. This is known as processor affinity.
• Two forms:
1) Soft Affinity
 When an OS try to keep a process on one processor because of policy, but cannot guarantee
it will happen.
 It is possible for a process to migrate between processors.
2) Hard Affinity
 When an OS have the ability to allow a process to specify that it is not to migrate to other
processors. Eg: Solaris OS

Load Balancing
• This attempts to keep the workload evenly distributed across all processors in an SMP system.
• Two approaches:
1) Push Migration
 A specific task periodically checks the load on each processor and if it finds an imbalance, it
evenly distributes the load to idle processors.
2) Pull Migration
 An idle processor pulls a waiting task from a busy processor.

Symmetric Multithreading
• The basic idea:
1) Create multiple logical processors on the same physical processor.
2) Present a view of several logical processors to the OS.
• Each logical processor has its own architecture state, which includes general-purpose and machine-
state registers.
• Each logical processor is responsible for its own interrupt handling.
• SMT is a feature provided in hardware, not software.
 Thread Scheduling
• On OSs, it is kernel-level threads but not processes that are being scheduled by the OS.
• User-level threads are managed by a 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.

Contention Scope
• Two approaches:
1) Process-Contention scope
 On systems implementing the many-to-one and many-to-many models, the thread library
schedules user-level threads to run on an available LWP.
 Competition for the CPU takes place among threads belonging to the same process.
2) System-Contention scope
 The process of deciding which kernel thread to schedule on the CPU.
 Competition for the CPU takes place among all threads in the system.
 Systems using the one-to-one model schedule threads using only SCS.

Pthread Scheduling
• Pthread API that allows specifying either PCS or SCS during thread creation.
• Pthreads identifies the following contention scope values:
1) PTHREAD_SCOPEJPROCESS schedules threads using PCS scheduling.
2) PTHREAD-SCOPE_SYSTEM schedules threads using SCS scheduling.
• Pthread IPC provides following two functions for getting and setting the contention scope policy:
1) pthread_attr_setscope(pthread_attr_t *attr, int scope)
2) pthread_attr_getscope(pthread_attr_t *attr, int *scope)
 Exercise Problems

1) Consider the following set of processes, with length of the CPU burst time given in milliseconds:
Process Arrival Time Burst Time Priority
P1 0 10 3
P2 0 1 1
P3 3 2 3
P4 5 1 4
P5 10 5 2
(i) Draw four Gantt charts illustrating the execution of these processing using FCFS, SJF, a non
preemptive priority and RR (Quantum=2) scheduling.
(ii) What is the turn around time of each process for each scheduling algorithm in (i).
(iii) What is waiting time of each process in (i)

Solution:

(i) FCFS:

Average waiting time = (0+10+8+8+4)/5 = 6

Average turnaround time = (10+11+13+14+19)/5 = 13.4

(ii) SJF (non-preemptive):

Average waiting time = (1+0+9+6+4)/5 = 4

Average turnaround time = (11+1+14+12+19)/5 = 11.4

SJF (preemptive):

Average waiting time = (4+0+0+0+4)/5 = 1.6

Average turnaround time = (14+1+5+6+19)/5 = 9

(iii) Non-preemptive, Priority:

Average waiting time = (1+0+13+13+1)/5 = 5.6

Average turnaround time = (11+1+18+19+16)/5 = 13

(iv) Round Robin (Quantum=2):

Average waiting time = (8+2+0+0+4)/5 = 2.8

Average turnaround time = (18+3+5+6+19)/5 = 10.2
2) Consider the following set of process with arrival time:
i) Draw grant chart using FCFS, SJF preemptive and non preemptive scheduling.
ii) Calculate the average waiting and turnaround time for each process of the scheduling
algorithm.
Process Arrival Time Burst Time
P1 0 10
P2 0 1
P3 1 2
P4 2 4
P5 2 3
Solution:
(i) FCFS:

Average waiting time = (0+10+10+11+15)/5 = 9.2

Average turnaround time = (10+11+13+17+20)/5 = 14.2

(ii) SJF (non-preemptive):

Average waiting time = (10+0+0+4+1)/5 = 3

Average turnaround time = (20+1+3+10+6)/5 = 8

(iii) SJF (preemptive):

Average waiting time = (10+0+0+4+1)/5 = 3

Average turnaround time = (20+1+3+10+6)/5 = 8
3) Consider following set of processes with CPU burst time (in msec)

Process Arrival Time Burst Time

P0 0 6
P1 1 3
P2 2 1
P3 3 4

i) Draw Gantt chart illustrating the execution of above processes using SRTF and non preemptive SJF
ii) Find the turnaround time for each process for SRTF and SJF. Hence show that SRTF is faster than
SJF.

Solution:

(i) Non-preemptive SJF:

Average waiting time = (0+6+4+7)/4 = 4.25

Average turnaround time = (6+10+7+14)/4 = 9.25

(ii) SRTF (preemptive SJF):

Average waiting time = (8+1+0+2)/4 = 2.75

Average turnaround time = (14+5+3+9)/4 = 7.75

Conclusion:
Since average turnaround time of SRTF(7.75) is less than SJF(9.25), SRTF is faster than SJF.
4) Following is the snapshot of a cpu

Process Arrival Time Burst Time

P1 0 10
P2 1 29
P3 2 03
P4 3 07

Draw Gantt charts and calculate the waiting and turnaround time using FCFS, SJF and RR with time
quantum 10 scheduling algorithms.

Solution:

(i) FCFS:

Average waiting time = (0+9+37+39)/4 = 21.25

Average turnaround time = (10+39+42+49)/4= 35

(ii) SJF (non-preemptive):

Average waiting time = (0+19+8+10)/4 = 9.25

Average turnaround time = (10+49+13+20)/4 =
19

SJF (preemptive):

Average waiting time = (11+19+0+2)/4 = 8

Average turnaround time = (21+49+5+12)/4 = 21.75

(iii) Round Robin (Quantum=10):

Average waiting time = (0+19+18+20)/4 = 14.25

Average turnaround time = (10+49+23+30)/4 =
28
5) Consider the following set of process:

Process Arrival Time Burst Time

P1 0 5
P2 1 1
P3 2 4

Compute average turn around time and average waiting time using
i) FCFS
ii) Preemptive SJF and
iii) RR (quantum-4).

Solution:

(i) FCFS:

Average waiting time = (0+4+4)/3 = 2.67

Average turnaround time = (5+6+10)/3 = 6.67

(ii) SJF (preemptive):

Average waiting time = (1+0+4)/3 = 1.67

Average turnaround time = (6+2+10)/3 = 6

(iii) Round Robin (Quantum=4):

Average waiting time = (5+3+3)/3 = 3.34

Average turnaround time = (10+5+9)/3 = 8
 MODULE 2 (CONT.): PROCESS SYNCHRONIZATION

Synchronization
• Co-operating process is one that can affect or be affected by other processes.
• Co-operating processes may either
→ share a logical address-space (i.e. code & data) or
→ share data through files or
→ messages through threads.
• Concurrent-access to shared-data may result in data-inconsistency.
• To maintain data-consistency:
The orderly execution of co-operating processes is necessary.
• Suppose that we wanted to provide a solution to producer-consumer problem that fills all buffers.
We can do so by having an variable counter that keeps track of the no. of full buffers.
Initially, counter=0.
 counter is incremented by the producer after it produces a new buffer.
 counter is decremented by the consumer after it consumes a buffer.
• Shared-data:

Producer Process: Consumer Process:

• A situation where several processes access & manipulate same data concurrently and the outcome of
the execution depends on particular order in which the access takes place, is called a race condition.
• Example:
counter++ could be implemented as: counter— may be implemented as:

• Consider this execution interleaving with counter = 5 initially:

• The value of counter may be either 4 or 6, where the correct result should be 5. This is an example
for race condition.
• To prevent race conditions, concurrent-processes must be synchronized.
 Critical-Section Problem
• Critical-section is a segment-of-code in which a process may be
→ changing common variables
→ updating a table or
→ writing a file.
• Each process has a critical-section in which the shared-data is accessed.
• General structure of a typical process has following (Figure 2.12):
1) Entry-section
 Requests permission to enter the critical-section.
2) Critical-section
 Mutually exclusive in time i.e. no other process can execute in its critical-section.
3) Exit-section
 Follows the critical-section.
4) Remainder-section

Figure 2.12 General structure of a typical process

• Problem statement:
―Ensure that when one process is executing in its critical-section, no other process is to be allowed
to execute in its critical-section‖ .
• A solution to the problem must satisfy the following 3 requirements:
1) Mutual Exclusion
 Only one process can be in its critical-section.
2) Progress
 Only processes that are not in their remainder-section can enter their critical-section, and the
selection of a process cannot be postponed indefinitely.
3) Bounded Waiting
 There must be a bound 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
the request is granted.
• Two approaches used to handle critical-sections:
1) Preemptive Kernels
 Allows a process to be preempted while it is running in kernel-mode.
2) Non-preemptive Kernels
 Does not allow a process running in kernel-mode to be preempted.
 Peterson’s Solution
• This is a classic software-based solution to the critical-section problem.
• This is limited to 2 processes.
• The 2 processes alternate execution between
→ critical-sections and
→ remainder-sections.
• The 2 processes share 2 variables (Figure 2.13):

where turn = indicates whose turn it is to enter its critical-section.

(i.e., if turn==i, then process Pi is allowed to execute in its critical-section).
flag = used to indicate if a process is ready to enter its critical-section.
(i.e. if flag[i]=true, then Pi is ready to enter its critical-section).

Figure 2.13 The structure of process Pi in Peterson‘s solution

• To enter the critical-section,

→ firstly process Pi sets flag[i] to be true and
→ then sets turn to the value j.
• If both processes try to enter at the same time, turn will be set to both i and j at roughly the same
time.
• The final value of turn determines which of the 2 processes is allowed to enter its critical-section first.
• To prove that this solution is correct, we show that:
1) Mutual-exclusion is preserved.
2) The progress requirement is satisfied.
3) The bounded-waiting requirement is met.
 Synchronization Hardware
Hardware based Solution for Critical-section Problem
• A lock is a simple tool used to solve the critical-section problem.
• Race conditions are prevented by following restriction (Figure 2.14).
―A process must acquire a lock before entering a critical-section.
The process releases the lock when it exits the critical-section‖ .

Figure 2.14: Solution to the critical-section problem using locks

Hardware instructions for solving critical-section problem

• Modern systems provide special hardware instructions
→ to test & modify the content of a word atomically or
→ to swap the contents of 2 words atomically.
• Atomic-operation means an operation that completes in its entirety without interruption.

TestAndSet()
• This instruction is executed atomically (Figure 2.15).
• If two TestAndSet() are executed simultaneously (on different CPU), they will be executed
sequentially in some arbitrary order.

Figure 2.15 The definition of the test and set() instruction

TestAndSet with Mutual Exclusion

• If the machine supports the TestAndSet(), we can implement mutual-exclusion by declaring a
boolean variable lock, initialized to false (Figure 2.16).

Figure 2.16 Mutual-exclusion implementation with test and set()

.
 Swap()
• This instruction is executed atomically (Figure 2.17).
• If the machine supports the Swap(), then mutual-exclusion can be provided as follows:
1) A global boolean variable lock is declared and is initialized to false.
2) In addition, each process has a local Boolean variable key (Figure 2.18).

Figure 2.17 The definition of swap() instruction

Figure 2.18 Mutual-exclusion implementation with the swap() instruction

Bounded waiting Mutual Exclusion with TestAndSet()

• Common data structures are

• These data structures are initialized to false (Figure 2.19).

Figure 2.19 Bounded-waiting mutual-exclusion with TestandSet()

 Semaphores
• A semaphore is a synchronization-tool.
• It used to control access to shared-variables so that only one process may at any point in time
change the value of the shared-variable.
• A semaphore(S) is an integer-variable that is accessed only through 2 atomic-operations:
1) wait() and
2) signal().
• wait() is termed P ("to test").
signal() is termed V ("to increment").
• Definition of wait(): Definition of signal():

• When one process modifies the semaphore-value, no other process can simultaneously modify that
same semaphore-value.
• Also, in the case of wait(S), following 2 operations must be executed without interruption:
1) Testing of S(S<=0) and
2) Modification of S (S--)
 Semaphore
Usage Counting
Semaphore
• The value of a semaphore can range over an unrestricted domain
Binary Semaphore
• The value of a semaphore can range only between 0 and 1.
• On some systems, binary semaphores are known as mutex locks, as they are locks that provide
mutual-exclusion.

1) Solution for Critical-section Problem using Binary Semaphores

• Binary semaphores can be used to solve the critical-section problem for multiple processes.
• The ‗n‘ processes share a semaphore mutex initialized to 1 (Figure 2.20).

Figure 2.20 Mutual-exclusion implementation with semaphores

2) Use of Counting Semaphores

• Counting semaphores can be used to control access to a given resource consisting of a finite number
o£ instances.
• The semaphore is initialized to the number of resources available.
• Each process that wishes to use a resource performs a wait() operation on the semaphore (thereby
decrementing the count).
• When a process releases a resource, it performs a signal() operation (incrementing the count).
• When the count for the semaphore goes to 0, all resources are being used.
• After that, processes that wish to use a resource will block until the count becomes greater than 0.

3) Solving Synchronization Problems

• Semaphores can also be used to solve synchronization problems.
• For example, consider 2 concurrently running-processes:
P1 with a statement S1 and
P2 with a statement S2.
• Suppose we require that S2 be executed only after S1 has completed.
• We can implement this scheme readily
→ by letting P1 and P2 share a common semaphore synch initialized to 0, and
→ by inserting the following statements in process P1

and the following statements in process P2

• Because synch is initialized to 0, P2 will execute S2 only after P1 has invoked signal (synch), which is
after statement S1 has been executed.
 Semaphore Implementation
• Main disadvantage of semaphore: Busy waiting.
• Busy waiting: While a process is in its critical-section, any other process that tries to enter its
critical-section must loop continuously in the entry code.
• Busy waiting wastes CPU cycles that some other process might be able to use productively.
• This type of semaphore is also called a spinlock (because the process "spins" while waiting for the
lock).
• To overcome busy waiting, we can modify the definition of the wait() and signal() as follows:
1) When a process executes the wait() and finds that the semaphore-value is not positive, it
must wait. However, rather than engaging in busy waiting, the process can block itself.
2) A process that is blocked (waiting on a semaphore S) should be restarted when some other
process executes a signal(). The process is restarted by a wakeup().
• We assume 2 simple operations:
1) block() suspends the process that invokes it.
2) wakeup(P) resumes the execution of a blocked process P.
• We define a semaphore as follows:

• Definition of wait(): Definition of signal():

• This (critical-section) problem can be solved in two ways:

1) In a uni-processor environment
¤ Inhibit interrupts when the wait and signal operations execute.
¤ Only current process executes, until interrupts are re-enabled & the scheduler regains
control.
2) In a multiprocessor environment
¤ Inhibiting interrupts doesn't work.
¤ Use the hardware / software solutions described above.

Deadlocks & Starvation

• Deadlock occurs when 2 or more processes are waiting indefinitely for an event that can be caused
by only one of the waiting processes.
• The event in question is the execution of a signal() operation.
• To illustrate this, consider 2 processes, Po and P1, each accessing 2 semaphores, S and Q. Let S and
Q be initialized to 1.

• Suppose that Po executes wait(S) and then P1 executes wait(Q).

When Po executes wait(Q), it must wait until P1 executes signal(Q).
Similarly, when P1 executes wait(S), it must wait until Po executes signal(S).
Since these signal() operations cannot be executed, Po & P1 are deadlocked.
• Starvation (indefinite blocking) is another problem related to deadlocks.
• Starvation is a situation in which processes wait indefinitely within the semaphore.
• Indefinite blocking may occur if we remove processes from the list associated with a semaphore in
LIFO (last-in, first-out) order.

.
 Classic Problems of Synchronization
1) Bounded-Buffer Problem
2) Readers and Writers Problem
3) Dining-Philosophers Problem

The Bounded-Buffer Problem

• The bounded-buffer problem is related to the producer consumer problem.
• There is a pool of n buffers, each capable of holding one item.
• Shared-data

where,
¤ mutex provides mutual-exclusion for accesses to the buffer-pool.
¤ empty counts the number of empty buffers.
¤ full counts the number of full buffers.
• The symmetry between the producer and the consumer.
¤ The producer produces full buffers for the consumer.
¤ The consumer produces empty buffers for the producer.
• Producer Process: Consumer Process:
 The Readers-Writers Problem
• A data set is shared among a number of concurrent processes.
• Readers are processes which want to only read the database (DB).
Writers are processes which want to update (i.e. to read & write) the DB.
• Problem:
 Obviously, if 2 readers can access the shared-DB simultaneously without any problems.
 However, if a writer & other process (either a reader or a writer) access the shared-DB
simultaneously, problems may arise.
Solution:
 The writers must have exclusive access to the shared-DB while writing to the DB.
• Shared-data

where,
¤ mutex is used to ensure mutual-exclusion when the variable readcount is updated.
¤ wrt is common to both reader and writer processes.
wrt is used as a mutual-exclusion semaphore for the writers.
wrt is also used by the first/last reader that enters/exits the critical-section.
¤ readcount counts no. of processes currently reading the object.
Initialization
mutex = 1, wrt = 1, readcount = 0
Writer Process: Reader Process:

• The readers-writers problem and its solutions are used to provide reader-writer locks on some
systems.
• The mode of lock needs to be specified:
1) read mode
 When a process wishes to read shared-data, it requests the lock in read mode.
2) write mode
 When a process wishes to modify shared-data, it requests the lock in write mode.
• Multiple processes are permitted to concurrently acquire a lock in read mode,
but only one process may acquire the lock for writing.
• These locks are most useful in the following situations:
1) In applications where it is easy to identify
→ which processes only read shared-data and
→ which threads only write shared-data.
2) In applications that have more readers than writers.
 The Dining-Philosophers Problem
• Problem statement:
 There are 5 philosophers with 5 chopsticks (semaphores).
 A philosopher is either eating (with two chopsticks) or thinking.
 The philosophers share a circular table (Figure 2.21).
 The table has
→ a bowl of rice in the center and
→ 5 single chopsticks.
 From time to time, a philosopher gets hungry and tries to pick up the 2 chopsticks that are
closest to her.
 A philosopher may pick up only one chopstick at a time.
 Obviously, she cannot pick up a chopstick that is already in the hand of a neighbor.
 When hungry philosopher has both her chopsticks at the same time, she eats without
releasing her chopsticks.
 When she is finished eating, she puts down both of her chopsticks and starts thinking again.
• Problem objective:
To allocate several resources among several processes in a deadlock-free & starvation-free manner.
• Solution:
 Represent each chopstick with a semaphore (Figure 2.22).
 A philosopher tries to grab a chopstick by executing a wait() on the semaphore.
 The philosopher releases her chopsticks by executing the signal() on the semaphores.
 This solution guarantees that no two neighbors are eating simultaneously.
 Shared-data
semaphore chopstick[5];
Initialization
chopstick[5]={1,1,1,1,1}.

Figure 2.21 Situation of dining philosophers Figure 2.22 The structure of philosopher

• Disadvantage:
1) Deadlock may occur if all 5 philosophers become hungry simultaneously and grab their left
chopstick. When each philosopher tries to grab her right chopstick, she will be delayed forever.
• Three possible remedies to the deadlock problem:
1) Allow at most 4 philosophers to be sitting simultaneously at the table.
2) Allow a philosopher to pick up her chopsticks only if both chopsticks are available.
3) Use an asymmetric solution; i.e. an odd philosopher picks up first her left chopstick and then
her right chopstick, whereas an even philosopher picks up her right chopstick and then her left
chopstick.
 Monitors
• Monitor is a high-level synchronization construct.
• It provides a convenient and effective mechanism for process synchronization.
Need for Monitors
• When programmers use semaphores incorrectly, following types of errors may occur:
1) Suppose that a process interchanges the order in which the wait() and signal() operations on
the semaphore ―mutex‖ are executed, resulting in the following execution:

 In this situation, several processes may be executing in their critical-sections simultaneously,

violating the mutual-exclusion requirement.
2) Suppose that a process replaces signal(mutex) with wait(mutex). That is, it executes

 In this case, a deadlock will occur.

3) Suppose that a process omits the wait(mutex), or the signal(mutex), or both.
 In this case, either mutual-exclusion is violated or a deadlock will occur.
 Monitors Usage
• A monitor type presents a set of programmer-defined operations that are provided to ensure
mutual-exclusion within the monitor.
• It also contains (Figure 2.23):
→ declaration of variables
→ bodies of procedures(or functions).
• A procedure defined within a monitor can access only those variables declared locally within the
monitor and its formal-parameters.
Similarly, the local-variables of a monitor can be accessed by only the local-procedures.

Figure 2.23 Syntax of a monitor

• Only one process at a time is active within the monitor (Figure 2.24).
• To allow a process to wait within the monitor, a condition variable must be declared, as

• Condition variable can only be used with the following 2 operations (Figure 2.25):
1) x.signal()
 This operation resumes exactly one suspended process. If no process is suspended, then the
signal operation has no effect.
2) x.wait()
 The process invoking this operation is suspended until another process invokes x.signal().

Figure 2.24 Schematic view of a monitor Figure 2.25 Monitor with condition variables
• Suppose when the x.signal() operation is invoked by a process P, there exists a suspended process Q
associated with condition x.
• Both processes can conceptually continue with their execution. Two possibilities exist:
1) Signal and wait
 P either waits until Q leaves the monitor or waits for another condition.
2) Signal and continue
 Q either waits until P leaves the monitor or waits for another condition.

Dining-Philosophers Solution Using Monitors

• The restriction is
 A philosopher may pick up her chopsticks only if both of them are available.
• Description of the solution:
1) The distribution of the chopsticks is controlled by the monitor dp (Figure 2.26).
2) Each philosopher, before starting to eat, must invoke the operation pickup(). This act may
result in the suspension of the philosopher process.
3) After the successful completion of the operation, the philosopher may eat.
4) Following this, the philosopher invokes the putdown() operation.
5) Thus, philosopher i must invoke the operations pickup() and putdown() in the following
sequence:

Figure 2.26 A monitor solution to the dining-philosopher problem

 Implementing a Monitor using Semaphores
• A process
→ must execute wait(mutex) before entering the monitor and
→ must execute signal(mutex) after leaving the monitor.
• Variables used:
semaphore mutex; // (initially = 1)
semaphore next; // (initially = 0)
int next-count = 0;
where
¤ mutex is provided for each monitor.
¤ next is used a signaling process to wait until the resumed process either leaves or waits
¤ next-count is used to count the number of processes suspended
• Each external procedure F is replaced by

• Mutual-exclusion within a monitor is ensured.

• How condition variables are implemented ?
For each condition variable x, we have:
semaphore x-sem; // (initially = 0)
int x-count = 0;
• Definition of x.wait() Definition of x.signal()
 Resuming Processes within a Monitor
• Problem:
If several processes are suspended, then how to determine which of the suspended processes
should be resumed next?
Solution-1: Use an FCFS ordering i.e. the process that has been waiting the longest is resumed first.
Solution-2: Use conditional–wait construct i.e. x.wait(c)
¤ c is a integer expression evaluated when the wait operation is executed (Figure 2.27).
¤ Value of c (a priority number) is then stored with the name of the process that is
suspended.
¤ When x.signal is executed, process with smallest associated priority number is
resumed next.

Figure 2.27 A monitor to allocate a single resource

• ResourceAllocator monitor controls the allocation of a single resource among competing processes.
• Each process, when requesting an allocation of the resource, specifies the maximum time it plans to
use the resource.
• The monitor allocates the resource to the process that has the shortest time-allocation request.
• A process that needs to access the resource in question must observe the following sequence:

where R is an instance of type ResourceAllocator.

• Following problems can occur:
 A process might access a resource without first gaining access permission to the resource.
 A process might never release a resource once it has been granted access to the resource.
 A process might attempt to release a resource that it never requested.
 A process might request the same resource twice.
 MODULE 3: DEADLOCKS
MEMORY MANAGEMENT

3.1. Deadlocks
3.2. System Model
3.3. Deadlock Characterization
3.3.1. Necessary Conditions
3.3.2. Resource Allocation Graph
3.4. Methods for Handling Deadlocks
3.5. Deadlock Prevention
3.5.1. Mutual Exclusion
3.5.2. Hold and Wait
3.5.3. No Preemption
3.5.4. Circular Wait
3.6. Deadlock Avoidance
3.6.1. Safe State
3.6.2. Resource Allocation Graph Algorithm
3.6.3. Banker's Algorithm
3.6.3.1. Safety Algorithm
3.6.3.2. Resource Request Algorithm
3.7. 3.3 An Illustrative Example
3.8. Deadlock Detection
3.8.1. Single Instance of Each Resource Type
3.8.2. Several Instances of a Resource Type
3.8.3. Detection Algorithm Usage
3.9. Recovery from Deadlock
3.9.1. Process Termination
3.9.2. Resource Preemption
3.10. Main Memory
3.10.1. Basic Hardware
3.10.2. Address Binding
3.10.3. Logical versus Physical Address Space
3.10.4. Dynamic Loading
3.10.5. Dynamic Linking and Shared Libraries
3.11. Swapping
3.12. Contiguous Memory Allocation
3.12.1. Memory Mapping & Protection
3.12.2. Memory Allocation
3.12.3. Fragmentation
3.13. Segmentation
3.14. Paging
3.14.1. Basic Method
3.14.2. Hardware Support for Paging
3.14.3. Protection
3.14.4. Shared Pages
3.15. Structure of the Page Table
3.15.1. Hierarchical Paging
3.15.2. Hashed Page Tables
3.15.3. Inverted Page Tables
3.16. Segmentation
3.16.1. Basic Method
3.16.2. Hardware Support
 MODULE 3: DEADLOCKS

Deadlocks
• Deadlock is a situation where a set of processes are blocked because each process is
→ holding a resource and
→ waiting for another resource held by some other process.
• Real life example:
When 2 trains are coming toward each other on same track and there is only one track, none of
the trains can move once they are in front of each other.
• Similar situation occurs in operating systems when there are two or more processes hold some
resources and wait for resources held by other(s).
• Here is an example of a situation where deadlock can occur (Figure 3.1).

Figure 3.1 Deadlock Situation

System Model
• A system consist of finite number of resources. (For ex: memory, printers, CPUs).
• These resources are distributed among number of processes.
• A process must
→ request a resource before using it and
→ release the resource after using it.
• The process can request any number of resources to carry out a given task.
• The total number of resource requested must not exceed the total number of resources available.
• In normal operation, a process must perform following tasks in sequence:
1) Request
 If the request cannot be granted immediately (for ex: the resource is being used by
another process), then the requesting-process must wait for acquiring the resource.
 For example: open( ), malloc( ), new( ), and request( )
2) Use
 The process uses the resource.
 For example: prints to the printer or reads from the file.
3) Release
 The process releases the resource.
 So that, the resource becomes available for other processes.
 For example: close( ), free( ), delete( ), and release( ).
• A set of processes is deadlocked when every process in the set is waiting for a resource that is
currently allocated to another process in the set.
• Deadlock may involve different types of resources.
• As shown in figure 3.2,
Both processes P1 & P2 need resources to continue
execution.
P1 requires additional resource R1 and is in
possession of resource R2.
P2 requires additional resource R2 and is in
possession of R1.
• Thus, neither process can continue.
• Multithread programs are good candidates for deadlock because
Figure 3.2 they compete for shared resources.

3-2
 Deadlock Characterization
• In a deadlock, processes never finish executing, and system resources are tied up, preventing other
jobs from starting.

Necessary Conditions
• There are four conditions that are necessary to achieve deadlock:
1) Mutual Exclusion
 At least one resource must be held in a non-sharable mode.
 If any other process requests this resource, then the requesting-process must wait for the
resource to be released.
2) Hold and Wait
 A process must be simultaneously
→ holding at least one resource and
→ waiting to acquire additional resources held by the other process.
3) No Preemption
 Once a process is holding a resource ( i.e. once its request has been granted ), then that
resource cannot be taken away from that process until the process voluntarily releases it.
4) Circular Wait
 A set of processes { P0, P1, P2, . . ., PN } must exist such that
P0 is waiting for a resource that is held by P1
P1 is waiting for a resource that is held by P2, and so on

3-3
 Resource-Allocation-Graph
• The resource-allocation-graph (RAG) is a directed graph that can be used to describe the deadlock
situation.
• RAG consists of a
→ set of vertices (V) and
→ set of edges (E).
• V is divided into two types of nodes
1) P={P1,P2….... Pn} i.e., set consisting of all active processes in the system.
2) R={R1,R2… ..... Rn} i.e., set consisting of all resource types in the system.
• E is divided into two types of edges:
1) Request Edge
 A directed-edge Pi → Rj is called a request edge.
 Pi → Rj indicates that process Pi has requested a resource Rj.
2) Assignment Edge
 A directed-edge Rj → Pi is called an assignment edge.
 Rj → Pi indicates that a resource Rj has been allocated to process Pi.
• Suppose that process Pi requests resource Rj.
Here, the request for Rj from Pi can be granted only if the converting request-edge to
assignment-edge do not form a cycle in the resource-allocation graph.
• Pictorially,
→ We represent each process Pi as a circle.
→ We represent each resource-type Rj as a rectangle.
• As shown in below figures, the RAG illustrates the following 3 situation (Figure 3.3):
1) RAG with a deadlock
2) RAG with a cycle and deadlock
3) RAG with a cycle but no deadlock

(a) Resource allocation Graph (b) With a deadlock (c) with cycle but no deadlock
Figure 3.3 Resource allocation graphs

Conclusion:
1) If a graph contains no cycles, then the system is not deadlocked.
2) If the graph contains a cycle then a deadlock may exist.
Therefore, a cycle means deadlock is possible, but not necessarily present.

3-4
 Methods for Handling Deadlocks
• There are three ways of handling deadlocks:
1) Deadlock prevention or avoidance - Do not allow the system to get into a deadlocked state.
2) Deadlock detection and recovery - Abort a process or preempt some resources when
deadlocks are detected.
3) Ignore the problem all together - If deadlocks only occur once a year or so, it may be better
to simply let them happen and reboot the system.
• In order to avoid deadlocks, the system must have additional information about all processes.
• In particular, the system must know what resources a process will or may request in the future.
• Deadlock detection is fairly straightforward, but deadlock recovery requires either aborting processes
or preempting resources.
• If deadlocks are neither prevented nor detected, then when a deadlock occurs the system will
gradually slow down.

Deadlock-Prevention
• Deadlocks can be eliminated by preventing at least one of the four required conditions:
1) Mutual exclusion
2) Hold-and-wait
3) No preemption
4) Circular-wait.

Mutual Exclusion
• This condition must hold for non-sharable resources.
• For example:
A printer cannot be simultaneously shared by several processes.
• On the other hand, shared resources do not lead to deadlocks.
• For example:
Simultaneous access can be granted for read-only file.
• A process never waits for accessing a sharable resource.
• In general, we cannot prevent deadlocks by denying the mutual-exclusion condition because some
resources are non-sharable by default.

Hold and Wait

• To prevent this condition:
The processes must be prevented from holding one or more resources while simultaneously
waiting for one or more other resources.
• There are several solutions to this problem.
• For example:
Consider a process that
→ copies the data from a tape drive to the disk
→ sorts the file and
→ then prints the results to a printer.
Protocol-1
 Each process must be allocated with all of its resources before it begins execution.
 All the resources (tape drive, disk files and printer) are allocated to the process at the
beginning.
Protocol-2
 A process must request a resource only when the process has none.
 Initially, the process is allocated with tape drive and disk file.
 The process performs the required operation and releases both tape drive and disk file.
 Then, the process is again allocated with disk file and the printer
 Again, the process performs the required operation & releases both disk file and the printer.
• Disadvantages of above 2 methods:
1) Resource utilization may be low, since resources may be allocated but unused for a long
period.
2) Starvation is possible.

3-5
 No Preemption
• To prevent this condition: the resources must be preempted.
• There are several solutions to this problem.
Protocol-1
• If a process is holding some resources and requests another resource that cannot be immediately
allocated to it, then all resources currently being held are preempted.
• The preempted resources are added to the list of resources for which the process is waiting.
• The process will be restarted only when it regains the old resources and the new resources that it is
requesting.
Protocol-2
• When a process request resources, we check whether they are available or not.
If (resources are available)
then
{
allocate resources to the process
}
else
{
If (resources are allocated to waiting process)
then
{
preempt the resources from the waiting process
allocate the resources to the requesting-process
the requesting-process must wait
}

}
• These 2 protocols may be applicable for resources whose states are easily saved and restored, such
as registers and memory.
• But, these 2 protocols are generally not applicable to other devices such as printers and tape drives.

Circular-Wait
• Deadlock can be prevented by using the following 2 protocol:
Protocol-1
 Assign numbers all resources.
 Require the processes to request resources only in increasing/decreasing order.
Protocol-2
 Require that whenever a process requests a resource, it has released resources with a lower
number.
• One big challenge in this scheme is determining the relative ordering of the different resources.

3-6
 Deadlock Avoidance
• The general idea behind deadlock avoidance is to prevent deadlocks from ever happening.
• Deadlock-avoidance algorithm
→ requires more information about each process, and
→ tends to lead to low device utilization.
• For example:
1) In simple algorithms, the scheduler only needs to know the maximum number of each
resource that a process might potentially use.
2) In complex algorithms, the scheduler can also take advantage of the schedule of exactly
what resources may be needed in what order.
• A deadlock-avoidance algorithm dynamically examines the resources allocation state to ensure that a
circular-wait condition never exists.
• The resource-allocation state is defined by
→ the number of available and allocated resources and
→ the maximum demand of each process.

Safe State
• A state is safe if the system can allocate all resources requested by all processes without entering a
deadlock state.
• A state is safe if there exists a safe sequence of processes {P0, P1, P2, ..., PN} such that
the requests of each process(Pi) can be satisfied by the currently available resources.
• If a safe sequence does not exist, then the system is in an unsafe state, which may lead to deadlock.
• All safe states are deadlock free, but not all unsafe states lead to deadlocks. (Figure 3.4).

Figure 3.4 Safe, unsafe, and deadlock state spaces

3-7
 Resource-Allocation-Graph Algorithm
• If resource categories have only single instances of their resources, then deadlock states can be
detected by cycles in the resource-allocation graphs.
• In this case, unsafe states can be recognized and avoided by augmenting the resource-allocation
graph with claim edges (denoted by a dashed line).
• Claim edge Pi → Rj indicated that process Pi may request resource Rj at some time in future.
• The important steps are as below:
1) When a process Pi requests a resource Rj, the claim edge Pi → Rj is converted to a request
edge.
2) Similarly, when a resource Rj is released by the process Pi, the assignment edge Rj → Pi is
reconverted as claim edge Pi → Rj.
3) The request for Rj from Pi can be granted only if the converting request edge to assignment
edge do not form a cycle in the resource allocation graph.
• To apply this algorithm, each process Pi must know all its claims before it starts executing.
• Conclusion:
1) If no cycle exists, then the allocation of the resource will leave the system in a safe state.
2) If cycle is found, system is put into unsafe state and may cause a deadlock.
• For example: Consider a resource allocation graph shown in Figure 3.5(a).
 Suppose P2 requests R2.
 Though R2 is currently free, we cannot allocate it to P2 as this action will create a cycle in the
graph as shown in Figure 3.5(b).
 This cycle will indicate that the system is in unsafe state: because, if P1 requests R2 and P2
requests R1 later, a deadlock will occur.

(a) For deadlock avoidance (b) an unsafe state

Figure 3.5 Resource Allocation graphs

• Problem:
The resource-allocation graph algorithm is not applicable when there are multiple instances
for each resource.
• Solution:
Use banker's algorithm.

3-8
 Banker's Algorithm
• This algorithm is applicable to the system with multiple instances of each resource types.
• However, this algorithm is less efficient then the resource-allocation-graph algorithm.
• When a process starts up, it must declare the maximum number of resources that it may need.
• This number may not exceed the total number of resources in the system.
• When a request is made, the system determines whether granting the request would leave the
system in a safe state.
• If the system in a safe state,
the resources are allocated;
else
the process must wait until some other process releases enough resources.
• Assumptions:
Let n = number of processes in the system
Let m = number of resources types.
• Following data structures are used to implement the banker’s algorithm.
1) Available [m]
 This vector indicates the no. of available resources of each type.
 If Available[j]=k, then k instances of resource type Rj is available.
2) Max [n][m]
 This matrix indicates the maximum demand of each process of each resource.
 If Max[i,j]=k, then process Pi may request at most k instances of resource type Rj.
3) Allocation [n][m]
 This matrix indicates no. of resources currently allocated to each process.
 If Allocation[i,j]=k, then Pi is currently allocated k instances of Rj.
4) Need [n][m]
 This matrix indicates the remaining resources need of each process.
 If Need[i,j]=k, then Pi may need k more instances of resource Rj to complete its task.
 So, Need[i,j] = Max[i,j] - Allocation[i]
• The Banker’s algorithm has two parts: 1) Safety Algorithm
2) Resource – Request Algorithm

Safety Algorithm
• This algorithm is used for finding out whether a system is in safe state or not.
• Assumptions:
Work is a working copy of the available resources, which will be modified during the analysis.
Finish is a vector of boolean values indicating whether a particular process can finish.

Step 1:
Let Work and Finish be two vectors of length m and n respectively.
Initialize:
Work = Available
Finish[i] = false for i=1,2,3,…….n
Step 2:
Find an index(i) such that both
a) Finish[i] = false
b) Need i <= Work.
If no such i exist, then go to step 4
Step 3:
Set:
Work = Work + Allocation(i)
Finish[i] = true
Go to step 2
Step 4:
If Finish[i] = true for all i, then the system is in safe state.

3-9
 Resource-Request Algorithm
• This algorithm determines if a new request is safe, and grants it only if it is safe to do so.
• When a request is made ( that does not exceed currently available resources ), pretend it has been
granted, and then see if the resulting state is a safe one. If so, grant the request, and if not, deny the
request.
• Let Request(i) be the request vector of process Pi.
• If Request(i)[j]=k, then process Pi wants K instances of the resource type Rj.

Step 1:
If Request(i) <= Need(i)
then
go to step 2
else
raise an error condition, since the process has exceeded its maximum claim.
Step 2:
If Request(i) <= Available
then
go to step 3
else
Pi must wait, since the resources are not available.
Step 3:
If the system want to allocate the requested resources to process Pi then modify the
state as follows:
Available = Available – Request(i)
Allocation(i) = Allocation(i) + Request(i)
Need(i) = Need(i) – Request(i)
Step 4:
If the resulting resource-allocation state is safe,
then i) transaction is complete and
ii) Pi is allocated its resources.
Step 5:
If the new state is unsafe,
then i) Pi must wait for Request(i) and
ii) old resource-allocation state is restored.

3-10
 An Illustrative Example
Question: Consider the following snapshot of a system:
Allocation Max Available
A B C A B C A B C
P0 0 1 0 7 5 3 3 3 2
P1 2 0 0 3 2 2
P2 3 0 3 9 0 2
P3 2 1 1 2 2 2
P4 0 0 2 4 3 3

Answer the following questions using Banker's algorithm.

i) What is the content of the matrix need?
ii) Is the system in a safe state?
iii) If a request from process P1 arrives for (1 0 2) can the request be granted immediately?

Solution (i):
• The content of the matrix Need is given by
Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C
P0 7 4 3
P1 1 2 2
P2 6 0 0
P3 0 1 1
P4 4 3 1
Solution (ii):
• Applying the Safety algorithm on the given system,
Step 1: Initialization
Work = Available i.e. Work =3 3 2
……P0………P1……..P2……..P3……P4…..
Finish = | false | false | false | false | false |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (7 4 3)<=(3 3 2)  false
So P0 must wait.

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (1 2 2)<=(3 3 2)  true
So P1 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(3 3 2)+(2 0 0)=(5 3 2)
…….P0………P1…….P2…….P3… ... P4……
Finish = | false | true | false | false | false |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (6 0 0)<=(5 3 2)  false
So P2 must wait.

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (0 1 1)<=(5 3 2)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (5 3 2)+(2 1 1)=(7 4 3)
……P0………P1……P2………..P3…….P4….
Finish = | false | true | false | true | false |

3-11
 Step 2: For i=4
Finish[P4] = false and Need[P4]<=Work i.e. (4 3 1)<=(7 4 3)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(7 4 3)+(0 0 2)=(7 4 5)
……P0………P1……P2………P3…….P4…..
Finish= | false | true | false | true | true |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (7 4 3)<=(7 4 5)  true
So P0 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P0] =(7 4 5)+(0 1 0)=(7 5 5)
…..P0…….P1………P2…….P3…….P4….
Finish= | true | true | false | true | true |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (6 0 0) <=(7 5 5)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(7 5 5)+(3 0 2)=(10 5 7)
…..P0…….P1………P2…….P3…….P4….
Finish= | true | true | true | true | true |

Step 4: Finish[Pi] = true for 0<=i<=4

Hence, the system is currently in a safe state.
The safe sequence is <P1, P3, P4, P0, P2>.
Conclusion: Yes, the system is currently in a safe state.

Solution (iii): P1 requests (1 0 2) i.e. Request[P1]=1 0 2

• To decide whether the request is granted, we use Resource Request algorithm.
Step 1: Request[P1]<=Need[P1] i.e. (1 0 2)<=(1 2 2)  true.
Step 2: Request[P1]<=Available i.e. (1 0 2)<=(3 3 2)  true.
Step 3: Available = Available – Request[P1] = (3 3 2) - (1 0 2)= (2 3 0)
Allocation[P1] = Allocation[P1] + Request[P1] = (2 0 0) + (1 0 2)= (3 0 2)
Need[P1] = Need[P1] – Request[P1] = (1 2 2) - (1 0 2)= (0 2 0)
• We arrive at the following new system state:

Allocation Max Available

A B C A B C A B C
P0 0 1 0 7 5 3 2 3 0
P1 3 0 2 3 2 2
• The content of the matrix P2 3 0 2 9 0 2 Need is given by
Need = Max - P3 2 1 1 2 2 2 Allocation
• So, the content of Need P4 0 0 2 4 3 3 Matrix is:
Need
A B C
P0 7 4 3
P1 0 2 0
P2 6 0 0
P3 0 1 1
P4 4 3 1
• To determine whether this new system state is safe, we again execute Safety algorithm.
Step 1: Initialization
Here, m=3, n=5
Work = Available i.e. Work =2 3 0
…..P0………P1………P2……….P3…….P4….
Finish = | false | false | false | false | false |

3-12
 Step 2: For i=0
Finish[P0] = false and Need[P0]<=Work i.e. (7 4 3)<=(2 3 0)  false
So P0 must wait.

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (0 2 0)<=(2 3 0)  true
So P1 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(2 3 0)+(3 0 2)=(5 3 2)
……P0………P1…….P2………P3…….P4……
Finish = | false | true | false | false | false |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (6 0 0) <=(5 3 2)  false
So P2 must wait.

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (0 1 1)<=(5 3 2)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (5 3 2)+(2 1 1)=(7 4 3)
…..P0……….P1……P2……..P3…….P4…...
Finish = | false | true | false | true | false |

Step 2: For i=4

Finish[P4] = false and Need[P4]<=Work i.e. (4 3 1)<=(7 4 3)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(7 4 3)+(0 0 2)=(7 4 5)
……P0………P1……P2………P3…….P4….
Finish = | false | true | false | true | true |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (7 4 3)<=(7 4 5)  true
So P0 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P0] =(7 4 5)+(0 1 0)=(7 5 5)
……P0…….P1………P2……P3 ...... P4….
Finish = | true | true | false | true | true |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (6 0 0) <=(7 5 5)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(7 5 5)+(3 0 2)=(10 5 7)
…..P0…….P1………P2…….P3…….P4….
Finish= | true | true | true | true | true |

Step 4: Finish[Pi] = true for 0<=i<=4

Hence, the system is in a safe state.
The safe sequence is <P1, P3, P4, P0, P2>.
Conclusion: Since the system is in safe sate, the request can be granted.

3-13
 Deadlock Detection
• If a system does not use either deadlock-prevention or deadlock-avoidance algorithm then a
deadlock may occur.
• In this environment, the system must provide
1) An algorithm to examine the system-state to determine whether a deadlock has occurred.
2) An algorithm to recover from the deadlock.

Single Instance of Each Resource Type

• If all the resources have only a single instance, then deadlock detection-algorithm can be defined
using a wait-for-graph.
• The wait-for-graph is applicable to only a single instance of a resource type.
• A wait-for-graph (WAG) is a variation of the resource-allocation-graph.
• The wait-for-graph can be obtained from the resource-allocation-graph by
→ removing the resource nodes and
→ collapsing the appropriate edges.
• An edge from Pi to Pj implies that process Pi is waiting for process Pj to release a resource that Pi
needs.
• An edge Pi → Pj exists if and only if the corresponding graph contains two edges
1) Pi → Rq and
2) Rq → Pj.
• For example:
Consider resource-allocation-graph shown in Figure 3.6
Corresponding wait-for-graph is shown in Figure 3.7.

Figure 3.6 Resource-allocation-graph Figure 3.7 Corresponding wait-for-graph.

• A deadlock exists in the system if and only if the wait-for-graph contains a cycle.
• To detect deadlocks, the system needs to
→ maintain the wait-for-graph and
→ periodically execute an algorithm that searches for a cycle in the graph.

3-14
 Several Instances of a Resource Type
• The wait-for-graph is applicable to only a single instance of a resource type.
• Problem: However, the wait-for-graph is not applicable to a multiple instance of a resource type.
• Solution: The following detection-algorithm can be used for a multiple instance of a resource type.
• Assumptions:
Let ‘n’ be the number of processes in the system
Let ‘m’ be the number of resources types.
• Following data structures are used to implement this algorithm.
1) Available [m]
 This vector indicates the no. of available resources of each type.
 If Available[j]=k, then k instances of resource type Rj is available.
2) Allocation [n][m]
 This matrix indicates no. of resources currently allocated to each process.
 If Allocation[i,j]=k, then Pi is currently allocated k instances of Rj.
3) Request [n][m]
 This 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.
Step 1:
Let Work and Finish be vectors of length m and n respectively.
a) Initialize Work = Available
b) For i=0,1,2…..... n
if Allocation(i) != 0
then
Finish[i] = false;
else
Finish[i] = true;
Step 2:
Find an index(i) such that both
a) Finish[i] = false
b) Request(i) <= Work.
If no such i exist, goto step 4.
Step 3:
Set:
Work = Work + Allocation(i)
Finish[i] = true
Go to step 2.
Step 4:
If Finish[i] = false for some i where 0 < i < n, then the system is in a deadlock state.

Detection-Algorithm Usage
• The detection-algorithm must be executed based on following factors:
1) The frequency of occurrence of a deadlock. 2) The no. of processes affected by the deadlock.
• If deadlocks occur frequently, then the detection-algorithm should be executed frequently.
• Resources allocated to deadlocked-processes will be idle until the deadlock is broken.
• Problem:
Deadlock occurs only when some processes make a request that cannot be granted immediately.
• Solution 1:
 The deadlock-algorithm must be executed whenever a request for allocation cannot be
granted immediately.
 In this case, we can identify
→ set of deadlocked-processes and
→ specific process causing the deadlock.
• Solution 2:
 The deadlock-algorithm must be executed in periodic intervals.
 For example:
→ once in an hour
→ whenever CPU utilization drops below certain threshold

3-15
 Recovery from deadlock
• Three approaches to recovery from deadlock:
1) Inform the system-operator for manual intervention.
2) Terminate one or more deadlocked-processes.
3) Preempt(or Block) some resources.

Process Termination
• Two methods to remove deadlocks:
1) Terminate all deadlocked-processes.
 This method will definitely break the deadlock-cycle.
 However, this method incurs great expense. This is because
→ Deadlocked-processes might have computed for a long time.
→ Results of these partial computations must be discarded.
→ Probably, the results must be re-computed later.
2) Terminate one process at a time until the deadlock-cycle is eliminated.
 This method incurs large overhead. This is because
after each process is aborted,
deadlock-algorithm must be executed to determine if any other process is still deadlocked
• For process termination, following factors need to be considered:
1) The priority of process.
2) The time taken by the process for computation & the required time for complete execution.
3) The no. of resources used by the process.
4) The no. of extra resources required by the process for complete execution.
5) The no. of processes that need to be terminated for deadlock-free execution.
6) The process is interactive or batch.

Resource Preemption
• Some resources are taken from one or more deadlocked-processes.
• These resources are given to other processes until the deadlock-cycle is broken.
• Three issues need to be considered:
1) Selecting a victim
 Which resources/processes are to be pre-empted (or blocked)?
 The order of pre-emption must be determined to minimize cost.
 Cost factors includes
1. The time taken by deadlocked-process for computation.
2. The no. of resources used by deadlocked-process.
2) Rollback
 If a resource is taken from a process, the process cannot continue its normal execution.
 In this case, the process must be rolled-back to break the deadlock.
 This method requires the system to keep more info. about the state of all running processes.
3) Starvation
 Problem: In a system where victim-selection is based on cost-factors, the same process may
be always picked as a victim.
 As a result, this process never completes its designated task.
 Solution: Ensure a process is picked as a victim only a (small) finite number of times.

3-16
 Exercise Problems

1) Consider the following snapshot of a system:

Allocation Max Available
A B C A B C A B C
P0 0 0 2 0 0 4 1 0 2
P1 1 0 0 2 0 1
P2 1 3 5 1 3 7
P3 6 3 2 8 4 2
P4 1 4 3 1 5 7

Answer the following questions using Banker's algorithm:

i) What is the content of the matrix need?
ii) Is the system in a safe state?
iii) If a request from process P2 arrives for (0 0 2) can the request be granted immediately?

Solution (i):
• The content of the matrix Need is given by
Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C
P0 0 0 2
P1 1 0 1
P2 0 0 2
P3 2 1 0
P4 0 1 4
Solution (ii):
• Applying the Safety algorithm on the given system,
Step 1: Initialization
Work = Available i.e. Work =1 0 2
……P0………P1……..P2……..P3……P4…..
Finish = | false | false | false | false | false |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (0 0 2)<=(1 0 2)  true
So P0 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P0] =(1 0 2)+(0 0 2)=(1 0 4)
……P0………P1…….P2… ..... P3……P4….
Finish = | true | false | false | false | false |

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (1 0 1)<=(1 0 4)  true
So P1 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(1 0 4)+(1 0 0)=(2 0 4)
…….P0…….P1……P2………P3… .... P4…
Finish = | true | true | false | false | false |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 0 2)<=(2 0 4)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(2 0 4)+(1 3 5)=(3 3 9)
……P0…….P1…….P2…..... P3……P4….
Finish = | true | true | true | false | false |

3-17
 Step 2: For i=3
Finish[P3] = false and Need[P3]<=Work i.e. (2 1 0)<=(3 3 9)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (3 3 9)+(6 3 2)=(9 6 11)
…..P0……..P1……P2……..P3…….P4….
Finish = | true | true | true | true | false |

Step 2: For i=4

Finish[P4] = false and Need[P4]<=Work i.e. (0 1 4)<=(9 6 11)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(9 6 11)+(1 4 3)=(10 10 14)
……P0…….P1……..P2……P3…….P4….
Finish = | true | true | true | true | true |

Step 4: Finish[Pi] = true for 0<=i<=4

Hence, the system is currently in a safe state.
The safe sequence is <P0, P1, P2, P3, P4>.
Conclusion: Yes, the system is currently in a safe state.

Solution (iii): P2 requests (0 0 2) i.e. Request[P2]=0 0 2

• To decide whether the request is granted, we use Resource Request algorithm.
Step 1: Request[P2]<=Need[P2] i.e. (0 0 2) <= (1 3 7)  true.
Step 2: Request[P2]<=Available i.e. (0 0 2) <= (1 0 2)  true.
Step 3: Available = Available – Request[P2] = (1 0 2) - (0 0 2)= (1 0 0)
Allocation[P2] = Allocation[P2] + Request[P2] = (1 3 5) + (0 0 2)= (1 3 7)
Need[P2] = Need[P2] – Request[P2] = (0 0 2) - (0 0 2)= (0 0 0)
• We arrive at the following new system state:

Allocation Max Available

A B C A B C A B C
P0 0 0 2 0 0 4 1 0 0
P1 1 0 0 2 0 1
P2 1 3 7 1 3 7
P3 6 3 2 8 4 2
P4 1 4 3 1 5 7

• The content of the matrix Need is given by

Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C
P0 0 0 2
P1 1 0 1
P2 0 0 0
P3 2 1 0
P4 0 1 4
• To determine whether this new system state is safe, we again execute Safety algorithm.
Step 1: Initialization
Work = Available i.e. Work =2 3 0
....P0………P1…….P2……….P3…..P4…..
Finish = | false | false | false | false | false |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (0 0 2)<=(2 3 0)  false
So P0 must wait.

3-18
 Step 2: For i=1
Finish[P1] = false and Need[P1]<=Work i.e. (1 0 1)<=(2 3 0)  false
So P1 must wait.

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 0 0)<=(2 3 0)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(1 0 0)+(1 3 7)=(2 3 7)
.....P0…….P1……..P2…..P3. ...... P4….
Finish = | false | false | true | false | false |

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (2 1 0)<=(2 3 7)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (2 3 7)+(6 3 2)=(8 6 9)
....P0……….P1…….P2…….P3… ... P4…
Finish = | false | false | true | true | false |

Step 2: For i=4

Finish[P4] = false and Need[P4]<=Work i.e. (0 1 4)<=(8 6 9)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(8 6 9)+(0 1 4)=(8 7 13)
....P0……….P1…….P2…….P3… ... P4…
Finish = | false | false | true | true | true |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (0 0 2)<=(8 7 13)  true
So P0 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P0] =(8 7 13)+(0 0 2)=(8 7 15)
....P0……….P1…….P2…….P3…….P4…
Finish = | true | false | true | true | true |

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (1 0 1)<=(8 7 15)  true
So P1 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(8 7 15)+(1 0 0)=(9 7 15)
....P0……….P1…….P2……P3…….P4…
Finish = | true | true | true | true | true |

Step 4: Finish[Pi] = true for 0<=i<=4

Hence, the system is in a safe state.
The safe sequence is <P2, P3, P4, P0, P1>.
Conclusion: Since the system is in safe sate, the request can be granted.

3-19
2) For the following snapshot, find the safe sequence using Banker's algorithm:
The number of resource units is (A, B, C) which are (7, 7, 10) respectively.
Allocation Max Available
A B C A B C A B C
P1 2 2 3 3 6 8 7 7 10
P2 2 0 3 4 3 3
P3 1 2 4 3 4 4
Solution:
• The content of the matrix Need is given by
Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C
P1 1 4 5
P2 2 3 0
P3 2 2 0
• Applying the Safety algorithm on the given system,
Step 1: Initialization
Here, m=3, n=3
Work = Available i.e. Work =7 7 10
….P1………..P2….... P3…
Finish = | false | false | false |
Step 2: For i=1
Finish[P1] = false and Need[P1]<=Work i.e. (1 4 5)<=(7 7 10)  true
So P1 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(7 7 10)+(2 2 3)=(9 9 13)
……P1……P2……….P3….
Finish = | true | false | false |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (2 3 0) <=(9 9 13)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(9 9 13)+(2 0 3)=(11 9 16)
…..P1……P2…….P3……
Finish = | true | true | false |

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (2 2 0)<=(11 9 16)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (11 9 16)+(1 2 4)=(12 11 20)
……P1……P2…….P3….
Finish = | true | true | true |

Step 4: Finish[Pi] = true for 1<=i<=3

Hence, the system is currently in a safe state.
The safe sequence is <P1, P2, P3>.
Conclusion: Yes, the system is currently in a safe state.

3-20
3) Consider the following snapshot of resource-allocation at time t1.
Allocation Max Available
A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 0
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2
i) What is the content of the matrix need?
ii) Show that the system is not deadlock by generating one safe sequence
iii) At instance t, P2 makes one additional for instance of type C. Show that the system is deadlocked
if the request is granted. Write down deadlocked-processes.

Solution (i):
• The content of the matrix Need is given by
Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C
P0 0 0 0
P1 0 0 2
P2 0 0 0
P3 0 0 0
P4 0 0 0
Solution (ii):
• Applying the Safety algorithm on the given system,
Step 1: Initialization
Work = Available i.e. Work =0 0 0
……P0………P1…….P2… .... P3……P4…
Finish = | false | false | false | false | false |

Step 2: For i=0

Finish[P0] = false and Need[P0]<=Work i.e. (0 0 0)<=(0 0 0)  true
So P0 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P0] =(0 0 0)+(0 1 0)=(0 1 0)
…..P0………P1…….P2…….P3….... P4…
Finish = | true | false | false | false | false |

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (0 0 2)<=(0 1 0)  false
So P1 must wait.

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 0 0) <=(0 1 0)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(0 1 0)+(3 0 3)=(5 1 3)
....P0……P1…….P2……….P3…….P4…
Finish = | true | false | true | false | false |

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (0 0 0)<=(5 1 3)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (5 1 3)+(2 1 1)=(5 2 4)
…P0……P1………P2…….P3…….P4…
Finish = | true | false | true | true | false |

3-21
 Step 2: For i=4
Finish[P4] = false and Need[P4]<=Work i.e. (0 0 0)<=(5 2 4)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(5 2 4)+(0 0 2)=(5 2 6)
....P0……P1…….P2…….P3…….P4….
Finish = | true | false | true | true | true |

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (0 0 2)<=(5 2 6)  true
So P0 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(5 2 6)+(2 0 0)=(7 2 6)
...P0…….P1……..P2…….P3…….P4…
Finish= | true | true | true | true | true |

Step 4: Finish[Pi] = true for 0<=i<=4

Hence, the system is currently in a safe state.
The safe sequence is <P0, P2, P3, P4, P1>.
Conclusion: Yes, the system is currently in a safe state. Hence there is no deadlock in the system.

Solution (iii): P2 requests (0 0 1) i.e. Request[P1]=0 0 1

• To decide whether the request is granted, we use Resource Request algorithm.
Step 1: Request[P1]<=Need[P1] i.e. (0 0 1)<=(0 0 2)  true.
Step 2: Request[P1]<=Available i.e. (0 0 1)<=(0 0 0)  false.
Conclusion: Since Request[P1]>Available, we cannot process this request.
Since P2 will be in waiting state, deadlock occurs in the system.

3-22
4) For the given snapshot :

Allocation Max Available

A B C D A B C D A B C D
P1 0 0 1 2 0 0 1 2 1 5 2 0
P2 1 0 0 0 1 7 5 0
P3 1 3 5 4 2 3 5 6
P4 0 6 3 2 0 6 5 2
P5 0 0 1 4 0 6 5 6

Using Banker's algorithm:

i) What is the need matrix content?
ii) Is the system in safe state?
iii) If a request from process P2(0,4,2,0) arrives, can it be granted?

Solution (i):
• The content of the matrix Need is given by
Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C D
P1 0 0 0 0
P2 0 7 5 2
P3 1 0 0 2
P4 0 0 2 0
P5 0 6 4 2
Solution (ii):
• Applying the Safety algorithm on the given system,
Step 1: Initialization
Work = Available i.e. Work =1 5 2 0
....P1………P2…….P3……….P4…..P5…..
Finish = | false | false | false | false | false |

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (0 0 0 0)<=(1 5 2 0)  true
So P1 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P1] =(1 5 2 0)+(0 0 1 2)=(1 5 3 2)
....P1………P2…….P3…….P4… ... P5…
Finish = | true | false | false | false | false |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 7 5 2)<=(1 5 3 2)  false
So P2 must wait.

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (1 0 0 2)<=(1 5 3 2)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (1 5 3 2)+(1 3 5 4)=(2 8 8 6)
....P1………P2…….P3…….P4… ... P5…
Finish = | true | false | true | false | false |

Step 2: For i=4

Finish[P4] = false and Need[P4]<=Work i.e. (0 0 2 0)<=(2 8 8 6)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(2 8 8 6)+(0 6 3 2)=(2 14 11 8)
....P1………P2…….P3…….P4…….P5…
Finish = | true | false | true | true | false |

3-23
 Step 2: For i=5
Finish[P5] = false and Need[P5]<=Work i.e. (0 6 4 2)<=(2 14 11 8)  true
So P5 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P5] =(2 14 11 8)+(0 0 1 4)=(2 14 12 12)
....P1………P2…….P3…….P4……P5…
Finish = | true | false | true | true | true |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 7 5 2) <=(2 14 12 12)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(2 14 12 12)+(1 0 0 0)=( 3 14 12 12)
....P1………P2…….P3…….P4……P5…
Finish = | true | true | true | true | true |

Step 4: Finish[Pi] = true for 1<=i<=5

Hence, the system is currently in a safe state.
The safe sequence is <P1, P3, P4, P5, P2>.
Conclusion: Yes, the system is currently in a safe state.

Solution (iii): P2 requests (0 4 2 0) i.e. Request[P2]= 0 4 2 0

• To decide whether the request is granted, we use Resource Request algorithm.
Step 1: Request[P2]<=Need[P2] i.e. (0 4 2 0) <= (0 7 5 2)  true.
Step 2: Request[P2]<=Available i.e. (0 4 2 0) <= (1 5 2 0)  true.
Step 3: Available = Available – Request[P2] = (1 5 2 0) - (0 4 2 0)= (1 1 0 0)
Allocation[P2] = Allocation[P2] + Request[P2] = (1 0 0 0) + (0 4 2 0)= (1 4 2 0)
Need[P2] = Need[P2] – Request[P2] = (0 7 5 2) - (0 4 2 0)= (0 3 3 2)
• We arrive at the following new system state

Allocation Max Available

A B C D A B C D A B C D
P1 0 0 1 2 0 0 1 2 1 1 0 0
P2 1 4 2 0 1 7 5 0
P3 1 3 5 4 2 3 5 6
P4 0 6 3 2 0 6 5 2
P5 0 0 1 4 0 6 5 6

• The content of the matrix Need is given by

Need = Max - Allocation
• So, the content of Need Matrix is:
Need
A B C D
P1 0 0 0 0
P2 0 3 3 2
P3 1 0 0 2
P4 0 0 2 0
P5 0 6 4 2

• Applying the Safety algorithm on the given system,

Step 1: Initialization
Work = Available i.e. Work =1 1 0 0
....P1………P2…….P3………..P4…...P5….
Finish = | false | false | false | false | false |

Step 2: For i=1

Finish[P1] = false and Need[P1]<=Work i.e. (0 0 0 0)<=(1 1 0 0)  true
So P1 must be kept in safe sequence.

3-24
 Step 3: Work = Work + Allocation[P1] =(1 1 0 0)+(0 0 1 2)=(1 1 1 2)
....P1………P2…….P3……...P4 ..... P5…
Finish = | true | false | false | false | false |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 3 3 2)<=(1 1 1 2) false
So P2 must wait.

Step 2: For i=3

Finish[P3] = false and Need[P3]<=Work i.e. (1 0 0 2)<=(1 1 1 2)  true
So P3 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P3] = (1 1 1 2)+(1 3 5 4)=(2 4 6 6)
....P1……P2……….P3…….P4… ... P5….
Finish = | true | false | true | false | false |

Step 2: For i=4

Finish[P4] = false and Need[P4]<=Work i.e. (0 0 2 0)<=(2 4 6 6)  true
So P4 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P4] =(2 4 6 6)+(0 6 3 2)=(2 10 9 8)
....P1………P2…….P3…….P4…….P5….
Finish = | true | false | true | true | false |

Step 2: For i=5

Finish[P5] = false and Need[P5]<=Work i.e. (0 6 4 2)<=(2 10 9 8)  true
So P5 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P5] =(2 10 9 8)+(0 0 1 4)=(2 10 10 12)
....P1………P2…….P3…….P4……P5….
Finish = | true | false | true | true | true |

Step 2: For i=2

Finish[P2] = false and Need[P2]<=Work i.e. (0 3 3 2) <=(2 10 10 12)  true
So P2 must be kept in safe sequence.
Step 3: Work = Work + Allocation[P2] =(2 10 10 12)+(1 4 2 0)=(3 14 12 12)
....P1………P2……P3…….P4……P5….
Finish = | true | true | true | true | true |

Step 4: Finish[Pi] = true for 0<=i<=4

Hence, the system is currently in a safe state.
The safe sequence is <P1, P3, P4, P5, P2>.
Conclusion: Since the system is in safe sate, the request can be granted.

3-25
5) Consider a system containing ‘m’ resources of the same type being shared by ‘n’ processes.
Resources can be requested and released by processes only one at a time. Show that the system is
deadlock free if the following two conditions hold:
i) The maximum need of each process is between 1 and m resources
ii) The sum of all maximum needs is less than m+n.
Ans:
• Suppose N = Sum of all Needi
A = Sum of all Allocationi
M = Sum of all Maxi.
• Use contradiction to prove: Assume this system is not deadlock free.
• If there exists a deadlock state, then A=m because there's only one kind of resource and resources
can be requested and released only one at a time.
• From condition (ii), N+A = M<m+n
• So we get N+m <m +n.
• So we get N < n.
• It shows that at least one process i that Needi=0.
• From condition (i), Pi can release at least one resource.
• So, there are n-1 processes sharing ‘m’ resources now, condition (i) and (ii) still hold.
• Go on the argument, no process will wait permanently, so there's no deadlock.

6) Consider the traffic deadlock depicted in the figure given below, explain that the four necessary
conditions for dead lock indeed hold in this examples.

Ans:
• The four necessary conditions for a deadlock are:
1) Mutual exclusion
2) Hold-and-wait
3) No preemption and
4) Circular-wait.
• The mutual exclusion condition holds since only one car can occupy a space in the roadway.
• Hold-and-wait occurs where a car holds onto its place in the roadway while it waits to advance in the
roadway.
• A car cannot be removed (i.e. preempted) from its position in the roadway.
• Lastly, there is indeed a circular-wait as each car is waiting for a subsequent car to advance.
• The circular-wait condition is also easily observed from the graphic.

3-26
3-27