Operating System9

1
Operating System(9)

• Minyi Guo
• Dept. of Computer Science and Engineering,
• Shanghai Jiaotong University

2
Deadlock

• Resource
• Deadlocks
• Deadlock modeling
• Deadlock detection and recovery
• Deadlock avoidance and prevention

3
Strategies for dealing with Deadlocks

• Ignore just ignore the problem altogether
• Detection and recovery
• Prevention negating one of the four necessary
  conditions
• Dynamic avoidance careful resource allocation

4
Detect and Recovery

• Deadlock detection with one resource of each type
• by looking for cycles in the wait-for graph
• Deadlock detection with multiple resource of each
  type

5
Detection with Resource Graph
one resource of each type
6
Detection with Resource Graph

• If there is only one resource of each type,
  finding a cycle in the resource graph means there
  is a deadlock
• Depth-first search

7
Detection Deadlock
multiple resource of each type
8
Detection Deadlock

• Algorithm
• (1) Let NP1,P2,Pn, n processes
• (2) Find a Process Pi, for Ri A
• (if Rij Aj , for 1jm)
• (3) If no such process, goto (4)
• else remove Pi from N add Ci to A
  
• goto (2)
• (4) If N is not empty, the processes in N are
  deadlocked

9
Detection with Wait-for Graph
An example for the deadlock detection algorithm
10
Recovery from Deadlock

• Recovery through preemption
• take a resource from some other process
• depends on nature of the resource
• Recovery through rollback
• checkpoint a process periodically
• use this saved state
• restart the process if it is found deadlocked

11
Recovery from Deadlock

• Recovery through killing processes
• crudest but simplest way to break a deadlock
• kill one of the processes in the deadlock cycle
• the other processes get its resources
• choose process that can be rerun from the
  beginning

12
Deadlock Prevention

• Increase resources to decrease waiting
• this minimizes chance of deadlock
• Idea is to eliminate one of the four necessary
  conditions
• D?C1?C2?C3?C4
• ? C1?? C2?? C3?? C4?? D

13
Deadlock Prevention

• Attacking the Mutual Exclusion Condition
• Attacking the Hold and Wait Condition
• Attacking the No Preemption Condition
• Attacking the Circular Wait Condition

14
Attacking Mutual Exclusion

• Some devices (such as printer) can be spooled
• only the printer daemon uses printer resource
• thus deadlock for printer eliminated
• Not all devices can be spooled

15
Attacking Mutual Exclusion

• Principle
• Avoid assigning resource when not absolutely
  necessary
• As few processes as possible actually claim the
  resource

16
Attacking Hold Wait Condition

• Eliminate hold and wait
• Processes to request resources before starting
• a process never has to wait for what it needs

17
Attacking Hold Wait Condition

• Problems?
• May not know required resources at start of run
• Ties up resources others could be using

18
Attacking Hold Wait Condition

• Variation
• Process requesting resources must give up all
  resources first
• Then request all immediately needed
• It may wait if there is not enough resources

19
Attacking No Preemption Condition

• Allow Preemption!
• Can preempt CPU by saving its state to process
  control block and resuming later
• Can preempt memory by swapping memory out to disk
  and loading it back later
• Can we preempt the holding of a lock?

20
Attacking No Preemption Condition

• Some resource cannot be preempted
• Consider a process given the printer
• halfway through its job
• now forcibly take away printer
• ??

21
Attacking Circular Wait Condition

• Normally ordered resources
• (1) Imagesetter
• (2) Scanner
• (3) Plotter
• (4) printer
• All request made by a process must be in
  numerical order
• With the rule the resource allocation graph can
  never have cycles

22
Summary of Deadlock Prevention

• Mutual Exclusion spool everything
• Hold and wait request all resources initially
• No preemption takes resource away
• Circular wait order resource numerically

23
Deadlock Avoidance

• Dont get in a position where Deadlock becomes
  possible
• Use
• Safe Resource Trajectories

24
Resource Trajectories
25
Safe and Unsafe States
(a) (b)
(c) (d)
(e)
Demonstration that the state in (a) is safe
26
Safe and Unsafe States
(a) (b)
(c)
(d)
Demonstration that the sate in (b) is unsafe
27
Bankers Algorithm

• Derive from methods by bankers to grant loans
• Similar to reserving all resources at beginning
• but more efficient

28
Bankers Algorithm

• State maximum resource needs in advance
• but dont actually acquire the resources
• When thread later tries to acquire a resource,
  Bankers algorithm determines
• whether its safe to satisfy the request
• blocks the process when its not safe

29
Bankers Algorithm

• Safe means guaranteeing the ability for all
  processes to finish
• no possibility of deadlock
• Example use bankers algorithm to model a bank
  loaning money to its customers

30
Bankers Algorithm

• Bank has 6000
• Customers sign up with bank and establish a
  credit limit (maximum resource needed)
• They borrow money in stages (up to credit limit)
• When theyre done, they return all the money

31
Bankers Algorithm

• Ann asks for credit limit of 2000
• Bob asks for credit limit of 4000
• Charlie asks for credit limit of 6000
• Can bank approve all these credit lines
• if it promises to give money upon request if
  available?
• everybody may wait when request money

32
Bankers Algorithm

• Ann asks for credit limit of 2000 (bank oks)
• Bob asks for credit limit of 4000 (bank oks)
• Charlie asks for credit limit of 6000 (bank oks)
• Ann takes out 1000 (bank has 5000 left)
• Bob takes out 2000 (bank has 3000 left)
• Charlie wants to take out 2000. Is this allowed?

33
Bankers Algorithm

• What about this scenario?
• Ann asks for credit limit of 2000 (bank oks)
• Bob asks for credit limit of 4000 (bank oks)
• Charlie asks for credit limit of 6000 (bank
  oks)
• Ann takes out 1000 (bank has 5000 left)
• Bob takes out 2000 (bank has 3000 left)
• Charlie wants to take out 2500. Is this
  allowed?

34
The Banker's Algorithm for a Single Resource
(a)
(b)
(c)
Three resource allocation states
35
Banker's Algorithm for Multiple Resources
36
Ignore Strategy

• Ostrich algorithm Pretend there is no problem
• Reasonable if
• deadlocks occur very rarely
• cost of prevention is high
• UNIX and Windows takes this approach
• A trade off between convenience correctness

37
Other Issues

• Two-Phase Locking
• Nonresource Deadlocks
• Starvation

38
Two-Phase Locking

• Phase One
• process tries to lock all records it needs, one
  at a time
• if needed record found locked, release all its
  locks and start all over
• no real work done in phase one

39
Two-Phase Locking

• If phase one succeeds, it starts second phase,
• performing updates
• releasing locks

40
Two-Phase Locking

• Note similarity to requesting all resources at
  once
• Algorithm works where programmer can arrange
• program can be stopped, restarted

41
Nonresource Deadlocks

• Possible for two processes to deadlock
• each is waiting for the other to do some task
• Can happen with semaphores
• each process required to do a down() on two
  semaphores (mutex and another)
• if done in wrong order, deadlock results

42
Starvation

• Starvation Deadlock
• Solution
• First come first serve
• Changing policy

43
Homework

• Page186
• 13, 15, 18, 26
• Deadline Nov. 5th

44
Solution to Dinning Philosopher Problem

• Lets return to dining philosophers problem
• Approach
• Attacking the Hold and Wait Condition
• Attacking the Circular Wait Condition

45
A Solution with Semaphore

• define N 5 / of philosophers/
• define LEFT (iN-1)N / of Is left neighbor/
• define RIGHT (i1)N / of Is right neighbor/
• define THINKING 0
• define HUNGRY 1
• define EATING 2
• typedef int semaphore
• int stateN /array to keep track of everyones
  state/
• semaphore mutex1
• semaphore sN /one semaphore per philosopher/

46
A Solution with Semaphore

• void philosopher(int i)
• while(TRUE)
• think()
• take_forks(i) /acquire two forks or block/
• eat()
• put_forks(i) /put both forks on the table/

47
A Solution with Semaphore

• void take_forks(int i)
• down(mutex)
• stateiHUNGRY
• test(i) /try to acquire 2 forks/
• up(mutex)
• down(si) /block if forks were not
  acquired/

48
A Solution with Semaphore

• void put_forks(i)
• down(mutex)
• stateiTHINKING
• test(LEFT) /see if left neighbor can eat/
• test(RIGHT) /see if right neighbor can eat/
• up(mutex)

49
A Solution with Semaphore

• void test(i)
• if(stateiHUNGRY stateLEFT!EATING
• stateRIGHT!EATING)
• stateiEATING
• up(si)