1. Operating Systems Unit 4: – Dining Philosophers – Deadlock – Indefinite postponement Operating Systems

2. COP 5994 - Operating Systems2 Dining Philosophers

3. COP 5994 - Operating Systems3 Dining Philosophers Example monitor dp { enum {thinking, hungry, eating} state[5]; condition self[5]; void pickup(int i) // following slides void putdown(int i) // following slides void test(int i) // following slides void init() { for (int i = 0; i < 5; i++) state[i] = thinking; }

4. COP 5994 - Operating Systems4 Dining Philosophers void pickup(int i) { state[i] = hungry; test(i); if (state[i] != eating) self[i].wait(); }

5. COP 5994 - Operating Systems5 Dining Philosophers void putdown(int i) { state[i] = thinking; // test left and right neighbors test((i+4) % 5); test((i+1) % 5); }

6. COP 5994 - Operating Systems6 Dining Philosophers void test(int i) { if ( (state[(i + 4) % 5] != eating) && (state[i] == hungry) && (state[(i + 1) % 5] != eating)) { state[i] = eating; self[i].signal(); }

7. COP 5994 - Operating Systems7 Java Monitors enables thread mutual exclusion and synchronization Signal-and-continue monitors –Allow a thread to signal that the monitor will soon become available –Maintain a lock on monitor until thread exits monitor method keyword synchronized

8. COP 5994 - Operating Systems8 Java Monitors wait method –releases lock on monitor, thread is placed in wait set –condition variable is “this” object –when thread reenters monitor, reason for waiting may not be met notify and notifyAll –signal waiting thread(s)

9. COP 5994 - Operating Systems9 Dining Philosopher with Semaphore ? semaphore chopstick[5]; // Initially set to 1 Philosopher i: do { wait(chopstick[i]) wait(chopstick[(i+1) % 5]) … eat … signal(chopstick[i]); signal(chopstick[(i+1) % 5]); … think … } while (1); Deadlock ?

10. COP 5994 - Operating Systems10 Deadlock

11. COP 5994 - Operating Systems11 Simple Resource Deadlock

12. COP 5994 - Operating Systems12 Related: Indefinite postponement Also called indefinite blocking or starvation –Occurs due to biases in a system’s resource scheduling policies Aging –Technique that prevents indefinite postponement by increasing process’s priority as it waits for resource

13. COP 5994 - Operating Systems13 Concepts: sharing & preemption some resources may be shared –files, devices, code, … preemptible resources –e.g. processors and main memory –can be removed from a process without loss of work non-preemptible resources –e.g. tape drives and optical scanners –cannot be removed from the process without loss of work

14. COP 5994 - Operating Systems14 Conditions for Deadlock Mutual exclusion –resource accessed by only one process at a time Hold-and-wait-for –process holds resource(s) while waiting for other resource(s) No-preemption –system cannot remove resource from the process until the process has finished using the resource Circular-wait –processes are in a “circular chain” where each process is waiting for resource(s) of next process in chain

15. COP 5994 - Operating Systems15 Dealing with Deadlock Deadlock prevention Deadlock avoidance Deadlock detection Deadlock recovery

16. COP 5994 - Operating Systems16 Deadlock Prevention Condition a system to remove any possibility of deadlocks occurring –avoid the four deadlock conditions –mutual exclusion cannot be avoided

17. COP 5994 - Operating Systems17 Denying the “Wait-For” Condition process must request all resources at once inefficient resource allocation

18. COP 5994 - Operating Systems18 Denying the “No-Preemption” Condition preempt resource from process loss of work substantial overhead for process restart

19. COP 5994 - Operating Systems19 Denying the “Circular-Wait” Condition Use a linear ordering of resources –each resource gets unique number –process requests resources in ascending order Drawbacks –Requires the programmer to determine the ordering or resources for each system

20. COP 5994 - Operating Systems20 Dijkstra’s Banker’s Algorithm deadlock avoidance –less stringent than deadlock prevention –control resource allocation –yields better resource utilization idea: –grant resource to process in return for promise to release it in “finite time” –differentiate between safe and unsafe states –allocate resources to processes only if it results in safe state

21. COP 5994 - Operating Systems21 Banker’s Algorithm: assumptions fixed number of identical resources fixed number of processes max(P i ) : –maximum number of resources for Process P i loan(P i ) : –current number of resources held by Process P i claim(P i ) : –max(P i ) - loan(P i )

22. COP 5994 - Operating Systems22 Example: Safe State guarantees that all current processes can complete their work within a finite time P 2 may proceed to completion

23. COP 5994 - Operating Systems23 Example: Unsafe State no process can guarantee to complete

24. COP 5994 - Operating Systems24 Safe-State-to-Unsafe-State Transition P 3 requests an additional resource

25. COP 5994 - Operating Systems25 Banker’s Algorithm example safe or unsafe ? unsafe

26. COP 5994 - Operating Systems26 Weaknesses in the Banker’s Algorithm Requires fixed number of resources Requires fixed population of processes only requires granting all requests within “finite time” only requires that clients return resources within “finite time” Requires processes to state maximum needs in advance

27. COP 5994 - Operating Systems27 Deadlock Detection problem: –has deadlock occurred ? how to determine if deadlock has occurred –check for circular wait can incur significant runtime overhead

28. COP 5994 - Operating Systems28 Tool: Resource-Allocation Graph

29. COP 5994 - Operating Systems29 Tool: Resource-Allocation Graph

30. COP 5994 - Operating Systems30 Reduction of Resource-Allocation Graphs Rules –If a process’s resource requests may be granted, the graph may be reduced by that process –If a graph can be reduced by all its processes, there is no deadlock –If a graph cannot be reduced by all its processes, the irreducible processes constitute the set of deadlocked processes in the graph

31. COP 5994 - Operating Systems31 Example: Graph Reduction 1/4

32. COP 5994 - Operating Systems32 Example: Graph Reduction 2/4

33. COP 5994 - Operating Systems33 Example: Graph Reduction 3/4

34. COP 5994 - Operating Systems34 Example: Graph Reduction 4/4

35. COP 5994 - Operating Systems35 Process termination –Abort all deadlocked processes –Abort one process at a time until the deadlock cycle is eliminated considerations: –suspend/resume feature –checkpoint/rollback Deadlock Recovery

36. COP 5994 - Operating Systems36 In which order should we choose to abort? –Priority of the process –How long process has computed, and how much longer to completion –Resources the process has used –Resources process needs to complete –How many processes will need to be terminated –Is process interactive or batch? Deadlock Recovery

37. COP 5994 - Operating Systems37 Current Deadlock Strategies Deadlock is viewed as limited annoyance in personal computer systems –Some systems implement basic prevention methods –Some others ignore the problem, because checking deadlocks would reduce systems’ performance Deadlock continues to be an important research area

38. COP 5994 - Operating Systems38 Agenda for next week: Chapter 8 –Processor scheduling Read ahead !