Scribd
Upload
167 views25 pages

Unit 4 - Deadlock Prevention

The document discusses deadlock prevention techniques in operating systems. It describes four conditions necessary for deadlock and ways to invalidate them, such as holding requests until all resources are allocated or imposing a total ordering of resource types. It also explains Dijkstra's Bankers Algorithm for deadlock avoidance, which involves a "banker" allocating resources to ensure the system remains in a safe state where all processes can complete. An example of a safe versus unsafe state is provided. Weaknesses of the algorithm are that the number of resources and users are assumed fixed.

Uploaded by

Dharshana B
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
167 views25 pages

Unit 4 - Deadlock Prevention

The document discusses deadlock prevention techniques in operating systems. It describes four conditions necessary for deadlock and ways to invalidate them, such as holding requests until all resources are allocated or imposing a total ordering of resource types. It also explains Dijkstra's Bankers Algorithm for deadlock avoidance, which involves a "banker" allocating resources to ensure the system remains in a safe state where all processes can complete. An example of a safe versus unsafe state is provided. Weaknesses of the algorithm are that the number of resources and users are assumed fixed.

Uploaded by

Dharshana B
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

SRI KRISHNA ARTS AND SCIENCE COLLEGE

DEPARTMENT OF INFORMATION TECHNOLOGY AND COGNITIVE SYSTEMS

OPERATING SYSTEM

UNIT 4

Deadlock Prevention
Content

• Deadlock prevention

• Deadlock avoidance

SKASC 2
Deadlock Prevention
Invalidate one of the four necessary conditions for deadlock:

• Mutual Exclusion – not required for sharable resources


(e.g., read-only files); must hold for non-sharable
resources
• Hold and Wait – must guarantee that whenever a thread
requests a resource, it does not hold any other resources
• Require threads to request and be allocated all its resources
before it begins execution or allow thread to request resources
only when the thread has none allocated to it.
• Low resource utilization; starvation possible
Deadlock Prevention (Cont.)
• No Preemption:
• If a process that is holding some resources requests another
resource that cannot be immediately allocated to it, then all
resources currently being held are released
• Preempted resources are added to the list of resources for which
the thread is waiting
• Thread will be restarted only when it can regain its old resources,
as well as the new ones that it is requesting
• Circular Wait:
• Impose a total ordering of all resource types, and require that
each thread requests resources in an increasing order of
enumeration
DEADLOCK AVOIDANCE AND BANKERS
ALGORITHM
• If the necessary conditions for a deadlock to occur are in place, It is
still possible to avoid deadlock by being careful when resources are
allocated.

• Perhaps the most famous deadlock avoidance algorithm is Dijikistra’s


Bankers algorithm.

• it is called by this interesting name because it involves a banker who


makes loans and receives payment from a given source of capital .
Dijikistra’s Banker’s Algorithm
• When we refer to the resources in the following discussion , we mean
resources of the same type.

• The banker’s algorithm is easily extendable to pools of resources of


several different types

• For example consider the allocation of quantity, t of identical tape drives.


CONTD..

• An operating system shares a fixed number of equivalent tape drives


among a fixed number of users u

• Each user specifies in advance the maximum number of tape drives he


or she will need during the execution of his or her job on the system.

• The operating system will accept a user’s request if that user’s


maximum need for tape drives doesn’t exceed t.
CONTD..

• A user may obtain or release tape drives one by one.

• Sometimes a user may have to wait to obtain an additional tape


drive, but the operating system guarantees a finite wait.

• The current number of tape drives allocated to a user will never


exceed that user’s stated maximum need.
CONTD..
• If the operating system is able to satisfy a user’s maximum need for tape
drives, then the user guarantees that the tape drives will be used and
released to the operating system within a finite time.

• The current state of the system is called safe if it is possible for the
operating system to allow all current user to complete their jobs within a
finite time.

• Again it is assumed that tape drives are the only resource requested by
users.

• If not then the current system state is called unsafe.


CONTD..

• Now suppose there are n users

• Let loan(i) represent user i’s current loan of tape drives.

• If user 5 for example has been allocated four tape drives then
loan(5)=4.
CONTD..

• Let max(i) be the maximum need of user i so that if user 3 has a


maximum need of two tape drives then max(3)=2.

• Let claim(i) be the current claim of a user where a user’s claim


is equal to his maximum need minus the user’s current loan.
CONTD..

• If for example, user 7 has a maximum need of six tape drives and a
current loan of four tape drives, then we have

• Claim(7)=max(7)-loan(7) = 6-4=2

• The operating system controls t tape drives. Let a be the number of


tape drives still available for allocation.

• Then a is equal to t minus the sum of the loans to the various users.
CONTD..

• Dijikistra’s banker’s algorithm says to allocate tape drives to users


when the allocations result in safe states rather than in unsafe
states.

• A safe state is one in which total resource situation is such that all
users would eventually be able to finish.

• An unsafe state is one that might eventually lead to deadlock.


EXAMPLE OF A SAFE STATE

• Suppose a system has twelve equivalent tape drives, and three


users sharing the drives as in state I.

• STATE:1
SAFE STATE
• User(2) currently has a loan of four tape drivers and eventually need a max of
six or 2 additional drives.

• The system has 12 drives of which currently in use and 2 are available.

• If 2 drives are given to user(2) may run to completion.

• If user(2) return six, then 3 may be given to user(1), who may then finish and
return 4 tape drives to the system

• The system may give three to user(3). Who may now also finish. Thus the key
to a state being safe is that there is at least one way for all users to finish
UNSAFE STATE
• STATE 2:
CURRENT LOAN MAXIMUM NEED

USER(1) 8 10
USER(2) 2 5
USER(3) 1 3
AVAILABLE 1

• Here 11 of the system’s 12 tape drivers are currently in use and only
one drive is available for allocation.

• We cannot guarantees that all user will finish.


CONTD..

• A three way deadlock occur if indeed each process needs to


request at least one more drive before releasing any drivers to the
pool.

• An unsafe state does not imply the existence, or even the


eventual existence, of deadlock. What an unsafe state does imply
is simply that some fortunate sequence of events might lead to
deadlock.
EXAMPLE OF SAFE STATE TO UNSAFE STATE
CURRENT LOAN MAXIMUM NEED
USER(1) 1 4
USER(2) 4 6
USER(3) 5 8
AVAILABLE 2

• The state is know to be safe does not imply that all future states will be
safe.
• Our resource allocation policy must carefully consider before all
resources granting them.
• Suppose user(3) requests an additional resources if the system were to
grant this request then the new state would be
CURRENT LOAN MAXIMUM NEED
USER(1) 1 4
USER(2) 4 6
USER(3) 6 8
AVAILABLE 1

• Certainly state is not necessarily deadlocked . But state has gone from a
safe one to an unsafe state. One resources is available .

• A minimum of two resources must be available to ensure that either


user(2) or user(3), return it resources to the system, and ultimately allow
the user to finish.
BANKER’S ALGORITHM RESOURCE ALLOCATION

• Process do claim exclusive use of resources they require processes


are indeed allowed to hold resources while requesting and waiting
for the additional resources, and resources may not be preempted
from a process holding those resources.
CONTD..

• The system grant or deny each request

• Request denied – user holds any allocated resources and wait for a
finite time.

• Request grant - that result in safe state only.


WEAKNESS IN BANKERS ALGORITHM
1. FIXED NO OF RESOUCES TO ALLOCATE - Since resources frequently
require service, either because of breakdown or preventive maintenance,
we cannot count on the number of resources constantly remain fixed.

2. FIXED NO USER – multi programmed systems, the user population is


constantly changing. On a large timesharing system it is not unusual to
service 100 or more users simultaneously. But the population of users
change constantly
3.GRANT ALL REQUEST WITHIN A FINITE TIME: It requires that the
bankers grant all request within a finite time. The client (i.e.. jobs)repay all
loans within a finite time (i.e.. Return all resources.

4.USERS STATE THEIR MAX NEED IN ADVANCE: resources allocation


becoming increasingly dynamic, it is becoming more difficult to know user’s
maximum need. In fact as system provide more user friendly interface, it is
becoming common to have users who don’t have the slightest idea what their
resources needs are.
Operating System - 19CSS08

Test Your knowledge

CLICK HERE

SKASC 24
THANK YOU

SKASC 25

You might also like