Successfully reported this slideshow.

Lecture5

2,412 views

Published on

os

  • Be the first to comment

  • Be the first to like this

Lecture5

  1. 1. Concurrency: Principles of Deadlock Operating Systems Fall 2002
  2. 2. Processes and resources <ul><li>Processes need resources to run </li></ul><ul><ul><li>CPU, memory, disk, etc… </li></ul></ul><ul><ul><li>A process waiting for a resource cannot complete its execution until the resource becomes available </li></ul></ul><ul><li>There is only a finite amount of resources </li></ul><ul><ul><li>E.g., 1 CPU, 1 GB memory, 2 disks </li></ul></ul>
  3. 3. Concurrency and deadlocks <ul><li>In a multiprogramming system the total resource demand by all concurrently active processes exceeds by far the total amount of available resources </li></ul><ul><li>Processes compete for resources </li></ul><ul><ul><li>A process can grab the last instance of a resource A and wait for the resource B </li></ul></ul><ul><ul><li>Another process may hold B and wait for A </li></ul></ul><ul><ul><li>No one can proceed: Deadlock </li></ul></ul>
  4. 4. Deadlock <ul><li>Permanent blocking of a set of processes that either compete for system resources or communicate with each other </li></ul><ul><li>Involves conflicting needs for resources by two or more processes </li></ul><ul><li>There is no satisfactory solution in the general case </li></ul>
  5. 5. Deadlock in the everyday life 1 2 3 4
  6. 6. Deadlock in the everyday life
  7. 7. Deadlock when contending for the critical section
  8. 8. Example of Deadlock Progress of Q Release A Release B Get A Get B Get A Get B Release A Release B Progress of P A Required B Required A Required B Required deadlock inevitable 1 2 3 4 5 6 P and Q want A P and Q want B
  9. 9. Example of No Deadlock Progress of Q Release A Release B Get A Get B Get A Release A Get B Release B Progress of P A Required B Required A Required B Required 1 2 3 4 5 6 P and Q want A P and Q want B
  10. 10. Resource categories <ul><li>Reusable : Used by one process at a time and not depleted by that use </li></ul><ul><ul><ul><li>can be reused by other processes,may exist several instances </li></ul></ul></ul><ul><ul><li>Processors, memory, disks, tapes, etc. </li></ul></ul><ul><li>Consumable : Created (produced) and destroyed (consumed) by a process </li></ul><ul><ul><ul><li>Interrupts, signals, messages, and information in I/O buffers </li></ul></ul></ul>
  11. 11. Reusable resources and Deadlock <ul><li>Deadlock might occur if each process holds one resource and requests the other </li></ul><ul><li>E.g., Space is available for allocation of 200K </li></ul>P1 . . . . . . Request 80K bytes; Request 60K bytes; P2 . . . . . . Request 70K bytes; Request 80K bytes;
  12. 12. Consumable resources and Deadlock <ul><li>Example: Deadlock occurs if receive is blocking </li></ul>P1 . . . . . . Receive(P2); Send(P2); P2 . . . . . . Receive(P1); Send(P1);
  13. 13. Conditions for Deadlock <ul><li>Policy conditions </li></ul><ul><ul><li>Mutual exclusion </li></ul></ul><ul><ul><li>Hold-and-wait </li></ul></ul><ul><ul><li>No preemption </li></ul></ul><ul><li>Circular wait </li></ul>Process P1 Process P2 Requests Held by Requests Held By Resource B Resource A
  14. 14. Conditions for Deadlock <ul><ul><li>Mutual exclusion </li></ul></ul><ul><ul><li>Hold-and-wait </li></ul></ul><ul><ul><li>No preemption </li></ul></ul><ul><ul><li>Circular wait </li></ul></ul>DEADLOCK
  15. 15. Circular Wait P1 P2 P3 R1 R2 R3
  16. 16. No circular wait P1 P2 P3 R1 R2 R3
  17. 17. Coping with Deadlocks <ul><li>Deadlock prevention </li></ul><ul><ul><li>Deadlock possibility is excluded a priori by the system design </li></ul></ul><ul><li>Deadlock avoidance </li></ul><ul><ul><li>Deadlocks are possible in principle but avoided </li></ul></ul><ul><li>Deadlock detection </li></ul><ul><ul><li>Deadlocks can occur: detect and solve the problem </li></ul></ul>
  18. 18. Deadlock prevention <ul><li>Design system so that it violates one of the four necessary conditions </li></ul><ul><ul><li>Prevent hold and wait: </li></ul></ul><ul><ul><ul><li>request all the resources at the outset </li></ul></ul></ul><ul><ul><ul><li>wait until all the resources are available </li></ul></ul></ul><ul><ul><li>Prevent circular wait by defining linear ordering of the resource types </li></ul></ul><ul><ul><ul><li>A process holding some resources can request only resource types with higher numbers </li></ul></ul></ul>
  19. 19. Preventing circular wait P1 P2 P3 R1 R2 R3
  20. 20. Deadlock prevention: Cons <ul><li>Degraded performance </li></ul><ul><ul><li>Delayed execution </li></ul></ul><ul><ul><li>Low parallelism </li></ul></ul><ul><li>Hold and wait prevention is wasteful </li></ul><ul><ul><li>Hold resources more than they are needed </li></ul></ul><ul><ul><li>When might this be reasonable? </li></ul></ul>
  21. 21. Deadlock avoidance <ul><li>Allocate resources in a way that assures that the deadlock point is never reached </li></ul><ul><li>The allocation decision is made dynamically based on </li></ul><ul><ul><li>total amount of resources available </li></ul></ul><ul><ul><li>currently available </li></ul></ul><ul><ul><li>processes’ resource claim </li></ul></ul><ul><ul><li>processes’ current resources allocation </li></ul></ul>
  22. 22. Banker’s algorithm ( Dijkstra 65’ ) <ul><li>Do not grant an incremental resource request to a process is this allocation might lead to deadlock </li></ul><ul><li>The system state : is the current allocation of resources to processes </li></ul><ul><li>Safe state: is a state in which there is at least one sequence in which all processes can be run to completion </li></ul><ul><li>Unsafe state = NOT safe state </li></ul>
  23. 23. Determination of the safe state <ul><li>We have 3 resources types with amount: </li></ul><ul><ul><li>R(1) = 9, R(2) = 3, R(3) = 6 </li></ul></ul><ul><li>Is the state S0 below safe? </li></ul>Claim Allocated Total 3 2 2 6 1 3 3 1 4 4 2 2 1 0 0 6 1 2 2 1 1 0 0 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 0 1 1
  24. 24. Determination of the safe state Claim Allocated Total 3 2 2 0 0 0 3 1 4 4 2 2 1 0 0 0 0 0 2 1 1 0 0 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 6 2 3 Claim Allocated Total 0 0 0 0 0 0 3 1 4 4 2 2 0 0 0 0 0 0 2 1 1 0 0 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 7 2 3
  25. 25. Determination of the safe state Claim Allocated Total 0 0 0 0 0 0 0 0 0 4 2 2 0 0 0 0 0 0 0 0 0 0 0 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 9 3 4 Claim Allocated Total 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 9 3 6 S0 is safe: P2->P1->P3->P4
  26. 26. Banker’s algorithm <ul><li>When a process request resources: </li></ul><ul><ul><li>Assume the request is granted </li></ul></ul><ul><ul><li>Update the system state accordingly </li></ul></ul><ul><ul><li>Determine whether the resulting state is safe </li></ul></ul><ul><ul><li>If yes: grant the resources </li></ul></ul><ul><ul><li>Otherwise, block the process until it is safe to grant the resources </li></ul></ul>
  27. 27. Banker’s algorithm Claim Allocated Total 3 2 2 6 1 3 3 1 4 4 2 2 1 0 0 5 1 1 2 1 1 0 0 2 P1 P2 P3 P4 R1 R2 R3 R1 R2 R3 R1 R2 R3 9 3 6 Available 1 1 2 P2 requests (1, 0, 1): Grant or not? P1 requests (1, 0, 1): Grant or not?
  28. 28. Deadlock detection <ul><li>Banker’s algorithm is </li></ul><ul><ul><li>Pessimistic: always assume that a process will not release the resources until it got’m all </li></ul></ul><ul><ul><ul><li>decreased parallelism </li></ul></ul></ul><ul><ul><li>Involves complicated checks for each resource allocation request (O(n^2)) </li></ul></ul><ul><li>Optimistic approach: don’t do any checks </li></ul><ul><ul><li>When deadlock occurs - detect and recover </li></ul></ul><ul><ul><li>Detection: look for circular waits </li></ul></ul>
  29. 29. Practice <ul><li>Most operating systems employ an “ostrich” algorithm </li></ul><ul><li>Break hold-and-wait </li></ul><ul><ul><li>Cannot acquire a resource - fail back to the user: </li></ul></ul><ul><ul><ul><li>e.g., too many processes, too many open files </li></ul></ul></ul><ul><li>Quotas </li></ul><ul><li>Programming discipline: </li></ul><ul><ul><li>acquire locks (semaphores) in a specific order </li></ul></ul>
  30. 30. Dining philosophers problem
  31. 31. Dining philosophers problem <ul><li>An abstract problem demonstrating some fundamental limitations of the deadlock-free synchronization </li></ul><ul><li>There is no symmetric solution </li></ul><ul><li>Solutions </li></ul><ul><ul><li>execute different code for odd/even </li></ul></ul><ul><ul><li>give’m another fork </li></ul></ul><ul><ul><li>allow at most 4 philosophers at the table </li></ul></ul><ul><ul><li>Randomized (Lehmann-Rabin) </li></ul></ul>
  32. 32. Concurrency: summary <ul><li>Critical section is an abstract problem for studying concurrency and synchronization </li></ul><ul><ul><li>software solutions </li></ul></ul><ul><ul><li>hardware primitives </li></ul></ul><ul><ul><li>higher level primitives: semaphores, monitors </li></ul></ul><ul><li>Deadlocks are inherent to concurrency </li></ul><ul><ul><li>4 conditions </li></ul></ul><ul><ul><li>3 ways to cope with </li></ul></ul>
  33. 33. Next: Memory management

×