Prepare for your exams
Get points
Guidelines and tips

Prepare for your exams

Study with the several resources on Docsity

Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips

Sell on Docsity

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search Store documents

The best documents sold by students who completed their studies

Search through all study resources

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents

20 Points

For each uploaded document

Answer questions

5 Points

For each given answer (max 1 per day)

All the ways to get free points

Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

University Rankings

Discover the best universities in your country according to Docsity users

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

From our blog

Exams and Study

Go to the blog

Operating Systems Lecture 10: Deadlock Prevention and Detection, Study notes of Operating Systems

University of San Diego (USD)Operating Systems

A part of the lecture notes for comp 310: operating systems, specifically lecture 10. The topic of the lecture is deadlock, including what it is, how to prevent it, how to detect it, and how to recover from it. The document also covers the concept of a resource allocation graph and the banker's algorithm.

Typology: Study notes

Pre 2010

Uploaded on 08/16/2009

koofers-user-qhl 🇺🇸

(1)

10 documents

1 / 11

This page cannot be seen from the preview

Don't miss anything!

COMP 310:

Operating Systems

Lecture 10:Deadlock

September 27, 2004

Christine Alvarado

Today’s Topics

Deadlock

What is it?

What can we do about it?

How do we avoid it?

How do we prevent it?

How do we detect it?

How do we recover from it?

Do we really need to do anything at all???

Partial preview of the text

Download Operating Systems Lecture 10: Deadlock Prevention and Detection and more Study notes Operating Systems in PDF only on Docsity!

COMP 310:

Operating Systems

Lecture 10:Deadlock

September 27, 2004

Christine Alvarado

Today’s Topics

 Deadlock

 What is it?

 What can we do about it?

 How do we avoid it?  How do we prevent it?  How do we detect it?  How do we recover from it?  Do we really need to do anything at all???

Last time: Conditions for Deadlock

 There are 4 conditions for deadlock to occur.

All for must hold simultaneously:

 Mutual Exclusion

 Hold and Wait

 No preemption

 Circular wait

Resource Allocation Graph R R R P1 P2 P

Resource Allocation Graph R R R P1 P2 P Cycles may = deadlock… But not always! Why have a RAG?

 Allows us to reason formally about possible

deadlock situation

 Many existing graph algorithms that we can

use.

Deadlock—What do we do about it?

 Ignore it: the ostrich approach

 Bury our head in the sand and pretend it won’t

happen

 Prevent it

 Make it so it can’t happen

 Avoid it

 Don’t give out resources if it allows possible

deadlock

 Detect and recover from it

Deadlock Prevention

 Make it so that one of our four conditions will

never be true

 What does this mean for each condition?

 Mutual Exclusion

Only use sharable resources. E.g., read-only files Not always possible

Deadlock Prevention

 Make it so that one of our four conditions will

never be true

 What does this mean for each condition?

 Circular Wait

Give each resource a number. Must request in numerical order. Can prove that this means no circular wait no DL F(R1) <F(R2)<F(R3)…<F(R1) Can waste time/resources Deadlock Avoidance

 Deadlock is not inherently prevented, but we

will avoid it

 Safe state:

 We can allocate resources to each process (up to

a maximum) in some order and avoid a deadlock.

 To show a state is safe we must find a safe

sequence.

 An ordering <P 1 , P 2 , … Pn> such that each Pi can be satisfied with available resources plus those used by processes earlier in the sequence.

Safe state example HOLDS WILL NEED (additional) P0 4 4 P1 1 6 P2 1 1 2 free resources HOLDS WILL NEED (additional) P0 5 5 P1 2 2 P2 7 2 3 free resources

SAFE

UNSAFE

(how could it not lead to DL?) Banker’s Algorithm

 Ensure that the system never gets into an unsafe

state

 Each process makes known its maximum needs

 System only allocates resources that keep the

system in a safe state

 Could fulfill everyone’s maximum in the right order

 Two algorithms needed:

 Safe state?  Resource allocation

Safe state verification algorithm

 Let Work = Available. Mark all processes as

unfinished.

 Find an unfinished process pi such that needi

< Work If there is no such process, failure

 Mark pi as finished

 Work += Allocationi

 If all processes finished, success

 Otherwise go to step 2

An example Allocation Max Available P1 5 9 2 P2 0 7 P3 4 6 Should P3 be given 2 resource? Should P2 be given 2 resources?

Deadlock detection

 Detect deadlock using modified “safety

algorithm”: Request instead of Need

 Let Work = Available. Mark all processes as

unfinished.

 Find an unfinished process pi such that requesti <

Work If there is no such process, failure

 Mark pi as finished

 Work += Allocationi

 If all processes finished, success

 Otherwise go to step 2

Only difference is that now we actually found deadlock We do this to maximize resource use (unsafe not always DL) So we found deadlock, now what?

Operating Systems Lecture 10: Deadlock Prevention and Detection, Study notes of Operating Systems

Related documents

Partial preview of the text

Download Operating Systems Lecture 10: Deadlock Prevention and Detection and more Study notes Operating Systems in PDF only on Docsity!

COMP 310:

Operating Systems

Lecture 10:Deadlock

September 27, 2004

Christine Alvarado

Today’s Topics

 Deadlock

 What is it?

 What can we do about it?

 There are 4 conditions for deadlock to occur.

All for must hold simultaneously:

 Mutual Exclusion

 Hold and Wait

 No preemption

 Circular wait

 Allows us to reason formally about possible

deadlock situation

 Many existing graph algorithms that we can

use.

 Ignore it: the ostrich approach

 Bury our head in the sand and pretend it won’t

happen

 Prevent it

 Make it so it can’t happen

 Avoid it

 Don’t give out resources if it allows possible

deadlock

 Detect and recover from it

 Make it so that one of our four conditions will

never be true

 What does this mean for each condition?

 Mutual Exclusion

 Make it so that one of our four conditions will

never be true

 What does this mean for each condition?

 Circular Wait

 Deadlock is not inherently prevented, but we

will avoid it

 Safe state:

 We can allocate resources to each process (up to

a maximum) in some order and avoid a deadlock.

 To show a state is safe we must find a safe

sequence.

SAFE

UNSAFE

 Ensure that the system never gets into an unsafe

state

 Each process makes known its maximum needs

 System only allocates resources that keep the

system in a safe state

 Two algorithms needed:

 Let Work = Available. Mark all processes as

unfinished.

 Find an unfinished process pi such that needi

< Work If there is no such process, failure

 Mark pi as finished

 Work += Allocationi

 If all processes finished, success

 Otherwise go to step 2

 Detect deadlock using modified “safety

algorithm”: Request instead of Need

 Let Work = Available. Mark all processes as

unfinished.

 Find an unfinished process pi such that requesti <

Work If there is no such process, failure

 Mark pi as finished

 Work += Allocationi

 If all processes finished, success

 Otherwise go to step 2

 Process termination:

 Kill all processes

 Kill one at a time

 Resource Preemption

 Selecting a victim

 Rollback

 Starvation