Dining Philosophers 0 1 0 class Philosopher: chopsticks[N] = [Semaphore(1),…] Deadlocks: 4 1 def __init__(mynum) self.id = mynum Prevention, Avoidance, 2 4 def eat(): 2 3 right = self.id Detection, Recovery left = (self.id+1) % N while True: 3 P(chopsticks[left]) N philosophers; N plates; N chopsticks P(chopsticks[right]) # om nom nom nom If all philosophers grab right chopstick V(chopsticks[right]) deadlock! V(chopsticks[left]) Need exclusive access to two chopsticks 1 2 Problematic Musings on Emergent Properties Deadlock & Starvation Starvation: Process waits forever Deadlock vs Starvation Deadlock: A set of processes exists, where each is Starvation: some thread’ s access to a resource is blocked and can become unblocked only by actions indefinitely postponed of another process in the set. Deadlock: circular waiting for resources Deadlock implies Starvation, but not vice versa T 1 T 2 { { “Subject to deadlock” does not imply “Will deadlock” P(file_mutex) P(printer_mutex) P(printer_mutex) P(file_mutex) semaphore: Testing is not the solution file_mutex = 1 /* use resources */ /* use resources */ printer_mutex = 1 System must be deadlock-free by design V(printer_mutex) V(file_mutex) V(file_mutex) V(printer_mutex) } } 4
A Graph Theoretic Model System Model of Deadlock Resource Allocation Graph Set of resources requiring “exclusive” access Computer system modeled as a RAG, a might be “k-exclusive access” if resource has directed graph G(V , E) capacity for k V = {P 1 ,…,P n } ⋃ {R 1 ,…,R n } R j Examples: CPU, printers, memory, locks, etc. P i Acquiring a resource can cause blocking: E = {edges from a resource to a process} ⋃ {edges from a process to a resource} if resource is free, then access is granted; process proceeds if resource is in use, then process blocks P i P k allocation request process uses resource edge edge process releases resource R j 5 6 Necessary Conditions RAG Reduction for Deadlock Deadlock possible only if all four hold Not sufficient in general R 1 R 3 Bounded resources (Acquire can block invoker) P 0 A finite number of threads can use a owned by resource; resources are finite waiting for P 1 P 2 P 3 No preemption Resource type with 5 instances P 4 P 1 the resource is mine, MINE! (until I release it) Hold & Wait cycle R 2 R 4 holds one resource while waiting for another Circular waiting Deadlock? T i waits for T i+1 and holds a resource NO! (no cycles) requested by T i-1 P 3 P 2 Step 1: Satisfy P 3 ’ s requests sufficient only if one instance of each Step 2: Satisfy P 2 ’ s requests resource Step 3: Satisfy P 1 ’ s requests Schedule [P 3 P 2 P 1 ] completely 7 8 eliminates edges!
RAG Reduction RAG Reduction R 1 R 1 R 3 R 1 R 3 R 1 R 3 R 1 R 3 P 2 P 1 P 3 P 1 P 2 P 3 P 1 P 2 P 3 P 1 P 2 P 3 P 1 P 2 P 3 P 4 R 2 R 2 R 4 R 2 R 4 R 2 R 4 R 2 R 4 Deadlock? Deadlock? Deadlock? Deadlock? Deadlock? NO! (no cycles) Yes! NO! (no cycles) Yes! NO! Step 1: Satisfy P 3 ’ s requests Step 1: Satisfy P 3 ’ s requests RAG has a cycle RAG has a cycle RAG has a cycle Step 2: Satisfy P 2 ’ s requests Step 2: Satisfy P 2 ’ s requests Cannot satisfy any of P 1 , P 2 , P 3 requests! Cannot satisfy any of P 1 , P 2 , P 3 requests! Schedule [P 2 P 1 P 3 P 4 ] completely Step 3: Satisfy P 1 ’ s requests Step 3: Satisfy P 1 ’ s requests eliminates edges! Schedule [P 3 P 2 P 1 ] completely 9 Schedule [P 3 P 2 P 1 ] completely 10 eliminates edges! eliminates edges! More Musings on Proactive Responses to Deadlock Deadlock: Prevention Does the order of RAG reduction matter? Negate one of deadlock’ s four necessary conditions No. If P i and P j can both be reduced, reducing P i Remove “Acquire can block invoker” does not affect the reducibility of P j Make resources sharable without locks Does a deadlock disappear on its own? Wait-free synchronization Make more resources available (duh!) No. Unless a process is killed or forced to release a resource, we are stuck! Remove “No preemption” If a system is not deadlock at time T, is it Allow OS to preempt resources of waiting processes guaranteed to be deadlock-free at T+1? Allow OS to preempt resources of requesting process if No. Just by requesting a resource (never mind being not all available granted one) a process can create a circular wait! 11
Proactive Responses to Proactive Responses to Deadlock: Prevention Deadlock: Prevention Negate one of deadlock’ s four necessary conditions Negate one of deadlock’ s four necessary conditions Remove “Hold & Wait” Remove “Circular waiting” Request all resources before execution begins Single lock for entire system? Processes may not know what they will need Impose total/partial order on resources Starvation (if waiting for many popular resources) Makes cycles impossible, since a cycle needs edges to go from Low utilization (if resource needed only for a bit) low to high, and then back to low Release all resources before asking anything new Still has the last two problems… Dining Philosophers Havender’ s Scheme (OS/360) (Again) Hierarchical Resource Allocation 0 1 Every resource is associated with a level. 0 acquire L 1 P i : do forever acquire(min(i, i+1 mod 7) 4 1 Rule H1 : All resources from a given level L 2 acquire(max(i, i+1 mod 7) must be acquired using a single request. eat release(min(i, i+1 mod 7) 2 4 release(max(i, i+1 mod 7) Rule H2 : After acquiring from level L j 2 3 end must not acquire from L i where i<j. 3 release Rule H3 : May not release from L i unless L n already released from L j where j>i. N philosophers; N plates; N chopsticks 16
Living dangerously: Living dangerously: Safe, Unsafe, Deadlocked States Safe, Unsafe, Deadlocked States Safe state: It is possible to avoid deadlock and eventually Unsafe grant all resource by careful scheduling (a safe schedule) Deadlock Transitioning among safe states may delay a resource request even when resources are available Unsafe state: Unlucky sequence of requests can force deadlock Safe Deadlocked state: System has at least one deadlock A system’ s trajectory through its state space 17 18 Why is George Bailey Proactive Responses to Deadlock: Avoidance The Banker’ s Algorithm in trouble? E.W . Dijkstra & N. Habermann If all his customers ask at the Processes declare worst-case needs (big assumption!), but then ask same time to have back all the for what they “really” need, a little at a time money they have lent, he is going Sum of maximum resource needs can exceed total available resources bankrupt Algorithm decides whether to grant a request But his bank is actually in a safe Build a graph assuming request granted state! Check whether state is safe (i.e., whether RAG is reducible) If only lenders delayed their requests, A state is safe if there exists some permutation of [P 1 , P 2 ,…,P n ] such that, for each P i , the all would be well! resources that P i can still request can be satisfied by the currently available resources plus the resources currently held by all P j , for P j preceding P i in the permutation spoiler alert: this is exactly what happens… Available = 3 Available resources can satisfy P 1 ’ s needs Max Process Holds Needs Once P 1 finishes, 5 available resources It still begs the question: Need P 0 10 5 5 Safe? Now, available resources can satisfy P 0 ’ s needs Once P 0 finishes, 10 available resources P 1 4 2 2 How can the OS allocate resources so Now, available resources can satisfy P 3 ’ s needs P 2 9 2 7 that the system always transitions Yes! Schedule: [P 1 , P 0 , P 3 ] among safe states? 19 20
Recommend
More recommend
