Outline

1. Outline • Deadlock • Deadlock definition • Conditions for a deadlock to occur • Deadlock prevention - Homework #1 is due today

2. Announcements • No recitation session this coming Wednesday • I will offer additional office hours during recitation sessions • Midterm will be Oct. 26, 2001 • A week from this coming Friday COP4610

3. Announcements – cont. • Lab1 • There are still five programs that do not have the correct permission • Lab1 grading will be available by tomorrow • You can pick up from Mr. Souza during his office hours and discuss with him any questions you may have • His office hours – Tuesday and Thursday 8:00-9:00am • Office location: NRB 319 COP4610

4. Announcements – cont. • Comments/suggestions about the class • I would appreciate your comments / suggestions / complaints about this class • There are some complaints and I will try to address those issues • The lectures are too “dry” • The lectures are too difficult COP4610

5. Review: Process Manager COP4610

6. Question #1 • If we use the test-and-set instruction (TS) to implement a counting semaphore, is the following implementation correct? Why? COP4610

7. Question #2 • Given that a monitor does not have any condition variable • How many processes can be running in the monitor at any time? • How many processes can be blocked in the monitor at any time? COP4610

8. Question #3 • A passive semaphore is used for mutual exclusion, will the bounded waiting be satisfied? COP4610

9. Question #4 • Let S and Q be two semaphores initialized to 1 P0P1 P(S); P(Q); P(Q); P(S);   V(S); V(Q); V(Q) V(S); • What is the potential problem? • How could we overcome this problem if we want to have least constraints on the programmers? COP4610

10. Deadlocks - Introduction • Kansas State legislature • “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other is gone” COP4610

11. Bridge Crossing Example • Traffic only in one direction. • Each section of a bridge can be viewed as a resource. • If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). • Several cars may have to be backed up if a deadlock occurs. • Starvation is possible. COP4610

12. Automobile Gridlocks COP4610

13. The Deadlock Problem • A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. • Example • System has 2 tape drives, one CD-ROM and one DAT drive. • P1 and P2 each hold one tape drive and each needs another one. COP4610

14. Two-process deadlock COP4610

15. Deadlock Examples – cont. • Semaphore example • semaphores A and B, initialized to 1 P0 P1 P (A); P(B); P(B); P(A); • Message deadlock example • Process A { receive(B, msg); send(B, msg): } • Process B { receive(A, msg); send(A, msg): } • Could result from a message being lost COP4610

16. Deadlock Examples – cont. COP4610

17. Deadlock Examples – cont. COP4610

18. System Model • Resource types R1, R2, . . ., Rm CPU cycles, memory space, I/O devices • Each resource type Ri has Wi instances • Each process utilizes a resource as follows • request • use • release • Examples include files, memory, and I/O devices COP4610

19. Deadlock Characterization • Deadlock can arise if four conditions hold simultaneously • Mutual exclusion • Hold and wait: • No preemption • Circular wait COP4610

20. Deadlock Characterization • Mutual exclusion • only one process at a time can use a resource. • Hold and wait: • a process holding at least one resource is waiting to acquire additional resources held by other processes. COP4610

21. Deadlock Characterization • No preemption • a resource can be released only voluntarily by the process holding it, after that process has completed its task. • Circular wait • there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0. COP4610

22. State Diagram • A set of states of a process or processes can be in and the transitions between them • Given a set of processes, • ri represents a request by pi • ai represents an allocation to pi • di represents a release by pi COP4610

23. State Diagram – cont. • State diagram of one process with one resource • of two units COP4610

24. State Diagram – cont. COP4610

25. Resource-Allocation Graph • A set of vertices V and a set of edges E. • V is partitioned into two types: • P = {P1, P2, …, Pn}, the set consisting of all the processes in the system • R = {R1, R2, …, Rm}, the set consisting of all resource types in the system • request edge – directed edge P1  Rj • assignment edge – directed edge Rj  Pi COP4610

26. Pi Rj Pi Rj Resource-Allocation Graph - cont. • Process • Resource Type with 4 instances • Pirequests instance of Rj • Pi is holding an instance of Rj COP4610

27. Example of a Resource Allocation Graph COP4610

28. Another Example of a Resource Allocation Graph COP4610

29. Yet Another Example of Resource Allocation Graph COP4610

30. Basic Facts • If graph contains no cycles  no deadlock. • If graph contains a cycle  • if only one instance per resource type, then deadlock. • if several instances per resource type, possibility of deadlock. COP4610

31. Dealing with Deadlocks • Three ways • Prevention • place restrictions on resource requests to make deadlock impossible • Avoidance • plan ahead to avoid deadlock. • Recovery • detect when deadlock occurs and recover from it COP4610

32. Deadlock Prevention • Restrain the ways that request can be made. • Mutual Exclusion – not required for sharable resources; must hold for nonsharable resources. • Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources. • Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none. • Low resource utilization; starvation possible. COP4610

33. Deadlock Prevention – cont. - Requesting all resources before starting COP4610

34. Deadlock Prevention – cont. - Release of all resources before requesting more COP4610

35. Deadlock Prevention - cont. • No Preemption – • If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released. • Preempted resources are added to the list of resources for which the process is waiting. • Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting. COP4610

36. Deadlock Prevention - cont. • An approach in the textbook, which is not • “full preemption” COP4610

37. Deadlock Prevention - cont. • Circular Wait • Impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration • Semaphore example • semaphores A and B, initialized to 1 P0 P1 wait (A); wait(A) wait (B); wait(B) COP4610

38. Deadlock Prevention - cont. COP4610

39. Deadlock Prevention - cont. COP4610

40. Two-phase locking • Each process has two stages • Stage 1 • acquire all resources you will need • if a resource is locked, then release all resources you are holding and start over • Stage 2 • Use the resources and do not release any • Stage 3 • then release all of them • Deadlock is prevented • No hold-and-wait COP4610

41. Summary • Deadlocks • Conditions for a deadlock to occur • Mutual exclusion • Hold and wait • Circular wait • No preemption • Deadlock prevention COP4610