Outline for today

1. Outline for today • Objective: • A little more concurrent programming practice. • Formal treatment of deadlock. • Administrative: • For all of you nameless ones, there are new tent-making materials in the folder. Don’t lose your names again!

2. Yet Another || Problem The Starbucharest espresso franchise serves customers FIFO in the following way. Each customer entering the shop takes a single “ticket” with a number from a “sequencer” on the counter. The ticket numbers dispensed by the sequencer are guaranteed to be unique and sequentially increasing. When a barrista is ready to serve the next customer, he or she calls out the “service count”, the lowest unserved number previously dispensed by the sequencer. Each customer waits until the service count reaches the number on their ticket. Each barrista waits until the customer with the ticket number called places an order. Show how to implement sequencers, tickets, and service counts using locks and condition variables. Your solution should include code for the barrista and customer threads.

3. int next (init to 0); int service_count (init to 0); condition turn, server; Customer {lock->acquire;next = next + 1; server->broadcast(lock);ticket = next; while (service_count < ticket) {turn->wait(lock);} lock->release;} Server {lock->acquire;while (next <= service_count) {server->wait(lock);}service_count = service_count + 1; turn->broadcast(lock);lock->release; } Class generated solution

4. Dealing with Deadlock It can be prevented by breaking one of the prerequisite conditions (review): • Mutually exclusive use of resources • Example: Allowing shared access to read-only files (readers/writers problem from readers point of view) • circular waiting • Example: Define an ordering on resources and acquire them in order (lower numbered fork first) • hold and wait • no pre-emption

5. Dealing with Deadlock (cont.) Let it happen, then detect it and recover • via externally-imposed preemption of resources Avoid dynamically by monitoring resource requests and denying some. • Banker’s Algorithm ...

6. The Zax Deadlock Example

7. Process P0 Request Arc Alloc Arc Resource R0 Resource R1 Process P1 Deadlock Theory State of resource allocation captured in Resource Graph • Bipartite graph model with a set P of vertices representing processes and a set R for resources. • Directed edges • RiPj means Ri alloc to Pj • PjRi means Pj requests Ri • Resource vertices contain units of the resource Reusable Resources

8. Process P0 Request Arc Alloc Arc Resource R0 Resource R1 Process P1 Deadlock Theory State transitions by operations: • Granting a request • Making a new request if all outstanding requests satisfied Deadlock defined on graph: • Pi is blocked in state S if there is no operation Pi can perform • Pi is deadlocked if it is blocked in all reachable states from S • S is safe if no reachable state is a deadlock state (i.e., having some deadlocked process)

9. Deadlock Theory P0 Request Arc • Cycle in graph is a necessary condition • no cycle no deadlock. • No deadlock iff graph is completely reducible • Intuition: Analyze graph, asking if deadlock is inevitable from this state by simulating most favorable state transitions. Alloc Arc R0 R1 P1 P3

10. The Zax Deadlock Example Z0 Z1 B0 B1

11. Deadlock Detection Algorithm Let U be the set of processes that have yet to be reduced. Initially U = P. Consider only reusable resources. while (there exist unblocked processes in U) { Remove unblocked Pi from U; Cancel Pi’s outstanding requests; Release Pi’s allocated resources; /* possibly unblocking other Pk in U */} if ( U != ) signal deadlock;

12. P0 Deadlock Detection Example P1 P2 R2 R4 R0 R3 R1 P3 P4

13. Deadlock Detection Example P1 P2 R2 R4 R0 R3 R1 P0 P3 P4

14. Deadlock Detection Example P2 R2 R4 R0 R3 R1 P0 P3 P4

15. Deadlock Detection Example P2 R2 R4 R0 R3 R1 P0 P3 P4

16. Deadlock Detection Example P2 R2 R4 R0 R3 R1 P0 P4

17. P0 Deadlock Detection Example P2 R2 R4 R0 R3 R1 P4

18. P0 Deadlock Detection Example R2 R4 R0 R3 R1 P4

19. P0 Deadlock Detection Example R2 R4 R0 R3 R1 P4

20. P0 Deadlock Detection Example R2 R4 R0 R3 R1

21. Deadlock Detection Example R2 R4 R0 R3 R1 Completely Reducible

22. Another Example P0 Request Arc Alloc Arc R0 R1 P1 With and without P2 P2

23. Another Example P0 Request Arc Alloc Arc R0 R1 P1 Is there an unblockedprocess to start with? With and without P2

24. Another Example P0 Request Arc Alloc Arc R0 R1 P1 With and without P2

25. Another Example P0 Request Arc Alloc Arc R0 R1 P1 With and without P2

26. Another Example P0 Request Arc Alloc Arc R0 R1 P1 With and without P2

27. Another Example P0 Request Arc Alloc Arc R0 R1 Is there an unblockedprocess to start with? P1 With and without P2 P2

28. R0 Producer Arc P0 P1 Producer Arc P2 R1 Consumable Resources • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units, 

29. Consumable Resources R0 Producer Arc P0 • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P2 P1 Producer Arc P2 R1

30. Consumable Resources R0 Producer Arc P0 • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P2 P1 Producer Arc P2 R1 Not reducible

31. R0 Producer Arc P0 P1 Producer Arc P2 R1 Consumable Resources • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P2

32. Consumable Resources R0 Producer Arc P0 • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P2 • Start with P1 P1 Producer Arc P2 R1

33. Consumable Resources R0 Producer Arc P0 • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P1  P1 Producer Arc P2 R1

34. Consumable Resources R0 Producer Arc P0 • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P1  P1 Producer Arc P2  R1

35. Consumable Resources R0 Producer Arc P0 • Not a fixed number of units, operations of producing and consuming (e.g. messages) • Ordering matters on applying reductions • Reducing by producer makes “enough” units,  • Start with P1 P1 Producer Arc P2 R1 Reducible

36. Deadlock Detection & Recovery • Continuous monitoring and running this algorithm are expensive. • What to do when a deadlock is detected? • Abort deadlocked processes (will result in restarts). • Preempt resources from selected processes, rolling back the victims to a previous state (undoing effects of work that has been done) • Watch out for starvation.

37. Avoidance - Banker’s Algorithm • Each process must declare its maximum claim on each of the resources and may never request beyond that level. • When a process places a request, the Banker decides whether to grant that request according to the following criteria: • “If I grant this request, then there is a run on the bank (everyone requests the remainder of their maximum claim), will we have deadlock?”

38. Representing the State • n processes, m resources • avail[m]- avail[i] is the number of available units of Ri • max[n,m] - max[i,j] is claim of Pi for Rj • alloc[n,m] - alloc[i,j] is current allocation of Rj to Pi • need[n,m] = max[n,m] - alloc[n,m] - the rest that can be requested. 4 7 2 5 2 2

39. Basic Outline of Algorithm request in ? if (request[i,j] > avail[j]) defer; //Sufficient resources for request //pretend to grant request avail[j] = avail [j] - request [i,j]; alloc[i,j] = alloc[i,j] + request [i,j]; need[i,j] = need[i,j] - request [i,j]; if (safe state) grant; else defer; 4 7-x 2 5 x 2 2 if (x = = 1)? if (x = = 2)?

40. Basic Outline of Algorithm request in ? if (request[i,j] > avail[j]) defer; //Sufficient resources for request //pretend to grant request avail[j] = avail [j] - request [i,j]; alloc[i,j] = alloc[i,j] + request [i,j]; need[i,j] = need[i,j] - request [i,j]; if (safe state) grant; else defer; 4 6 2 5 1 2 2 if (x = = 1)?

41. Basic Outline of Algorithm request in ? if (request[i,j] > avail[j]) defer; //Sufficient resources for request //pretend to grant request avail[j] = avail [j] - request [i,j]; alloc[i,j] = alloc[i,j] + request [i,j]; need[i,j] = need[i,j] - request [i,j]; if (safe state) grant; else defer; 4 6 2 5 1

42. Basic Outline of Algorithm request in ? if (request[i,j] > avail[j]) defer; //Sufficient resources for request //pretend to grant request avail[j] = avail [j] - request [i,j]; alloc[i,j] = alloc[i,j] + request [i,j]; need[i,j] = need[i,j] - request [i,j]; if (safe state) grant; else defer; 6 2 1

43. Basic Outline of Algorithm request in ? if (request[i,j] > avail[j]) defer; //Sufficient resources for request //pretend to grant request avail[j] = avail [j] - request [i,j]; alloc[i,j] = alloc[i,j] + request [i,j]; need[i,j] = need[i,j] - request [i,j]; if (safe state) grant; else defer; 4 5 2 5 2 2 2 if (x = = 2)?

44. Pulse – using speculation to detect deadlocks

45. Goal • To increase the kinds of deadlocks that can be detected dynamically • Uses high-level speculative execution to go forward to discover dependencies

46. Overview of Pulse • Kernel daemon process • Presence of long-sleeping processes trigger detection • Detection mode • Identify processes and events awaited • Fork speculative processes to see what events they generate in the future

47. Creating General Resource Graph with Consumable Resources

48. Details of Graph Construction • Process and Event nodes • Those processes blocked a long time. • Events – all blocking system calls modified to record the events for which caller waits(resource, condition <op, val>) • Edges • Request edges generated with event nodes. • Producer edges result from speculation • Recorded in event buffer until speculative processes terminate (normally, full buffer, timeout) • Modifying all system calls that unblock the blocking ones • Cycle detection on finished graph

49. Safe Speculation • Must not modify state of any other process • Fork with copy-on-write enabled • Can not change shared kernel data structures • Can not write to files • Can not send signals to another process • Pretend properly that we get unblocked ourselves • Not really reading input data if that’s what we were waiting for (so data dependent branches won’t be “right”) • Must pretend that conditions true (in case of while loop in application code)

50. Tricks of Forking Blocked Processes • New process is forced to run ret_from_spec_fork • Fake the awaited event • syscall_exit with success