1 / 54

ecs251 Fall 2007 : Operating System Models #3: Priority Inversion

ecs251 Fall 2007 : Operating System Models #3: Priority Inversion. Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com. Unexpected Effects between two OS control mechanisms. Real-time priority scheduling

maili
Download Presentation

ecs251 Fall 2007 : Operating System Models #3: Priority Inversion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ecs251 Fall 2007:Operating System Models#3: Priority Inversion Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com ecs251, fall 2007

  2. Unexpected Effectsbetween two OS control mechanisms • Real-time priority scheduling • Responsiveness: if a higher priority thread appears, serve it asap. • Mutual exclusion • Integrity: if a higher priority thread wants to enter a critical section being hold by a lower priority thread, it has to wait for the lower priority thread to leave “the critical section”. ecs251, fall 2007

  3. 1 RR 0 0 lock : : . 256 different priorities 64 scheduling classes unlock 1 0 1 ecs251, fall 2007

  4. Real-Time Threads • Thread τ1 L L L Rx L • Thread τ2 L L ... L • Thread τ3 L L L RxL ... L • L: local CPU burst • R: resource required (Mutual Exclusion) ecs251, fall 2007

  5. critical section Example • Suppose that threads τ1 and τ3 share some data. • Access to the data is restricted using semaphore x: • each task executes the following code: • do local work (L) • sem_wait(s) (P(x)) • access shared resource (R) • sem_signal(s) (V(x)) • do more local work (L) ecs251, fall 2007

  6. L L L Blocking Blocked! τ1 R L τ2 τ3 L L L L L L R R t+4 t+6 0 t t+3 ecs251, fall 2007

  7. L L L The middle thread Blocked! τ1 τ2 τ3 L L L R 0 t t+2 t+3 ecs251, fall 2007

  8. L L L ... L L Unbounded Priority Inversion Blocked! τ1 R L τ2 τ3 L L L R R t+253 t+254 0 t t+2 t+3 ecs251, fall 2007

  9. L L L Unbounded Priority Inversion Blocked! τ1 R L τ2-1 L τ2-2 L τ2-n L τ3 L L L R R t+2530 t+2540 0 t t+2 t+3 ecs251, fall 2007

  10. The problem.. • As long as we have priority and mutual exclusion at the same time, we will have some form of priority inversion. • How to resolve it? trade-off? ecs251, fall 2007

  11. L L L R dynamic 3 = 1 Priority Inheritance Blocked! τ1 R L L ... L τ2 τ3 L L L R L ... L 0 t t+2 t+3 t+4 t+6 ecs251, fall 2007

  12. Priority Inheritance Protocols • L. Sha, R. Rajkumar, J. Lehoczky, “Priority Inheritance Protocols: An Approach to Real-Time Synchronization”, IEEE Transactions on Computers, Vol. 39, No. 9, pp. 1175-1185, 1990 ecs251, fall 2007

  13. High priority: retrieval of data from shared memory Medium priority: communications task Low priority: thread collecting meteorological data “The meteorological data gathering task ran as an infrequent, low priority thread, and used the information bus to publish its data. When publishing its data, it would acquire a mutex, do writes to the bus, and release the mutex. If an interrupt caused the information bus thread to be scheduled while this mutex was held, and if the information bus thread then attempted to acquire this same mutex in order to retrieve published data, this would cause it to block on the mutex, waiting until the meteorological thread released the mutex before it could continue. The spacecraft also contained a communications task that ran with medium priority.” ecs251, fall 2007

  14. Basic Priority Inheritance • For each resource (semaphore), a list of blocked threads must be stored in a priority queue. • A thread τi uses its assigned priority, unless it is in its critical section and blocks some higher priority threads, in which case, thread τi uses ( inherits ) the highest dynamic priority of all the threads it blocks. • Priority inheritance is transitive; that is, if thread τi blocks τj and τj blocks τk , then τi can inherit the priority of τk. ecs251, fall 2007

  15. pthread_mutex_lock pthread_mutex_unlock Mutex Priority Inheritance waiting queue t t t t priority ecs251, fall 2007

  16. pthread_mutex_lock waiting queue M1 t t t priority pthread_mutex_unlock t pthread_mutex_lock waiting queue M2 t t t priority pthread_mutex_unlock ecs251, fall 2007

  17. Transitive Priority pthread_mutex_lock pthread_mutex_lock waiting queue waiting queue M2 M1 t t t t t t t priority priority pthread_mutex_unlock pthread_mutex_unlock ecs251, fall 2007

  18. Problems • The Basic Priority Inheritance Protocol has two problems: • Deadlock - two threads need to access a pair of shared resources simultaneously. If the resources, say A and B, are accessed in opposite orders by each thread, then deadlock may occur. • Blocking Chain - the blocking duration is bounded (by at most the sum of critical section times), but that may be substantial. ecs251, fall 2007

  19. Blocking Chain Example starting time • Task 1 : L R2 L R3 L R4L ... L Rn L, 2(n-1) • Task 2 : L R2 R2, 2(n-2) • Task 3 : L R3 R3, 2(n-3) • Task 4 : L R4 R4, 2(n-4) • ... • Task n-1 : L Rn-1 Rn-1, 2(n-(n-1)) • Task n : L Rn Rn, 2(n-n) ecs251, fall 2007

  20. L R2 L L R2 Rn R2 Blocking Chain Blocked! Blocked! τ1 Rn L τ2 τn L Rn 0 ecs251, fall 2007

  21. Priority Ceiling Protocols (PCP) • A higher priority thread can be blocked at most once, in its life time,by one lower priority thread. • Deadlocks are prevented/avoided (?!). • Transitive inheritance is prevented. • Are they really critical? ecs251, fall 2007

  22. PCP • How do we accomplish these goals intuitively? ecs251, fall 2007

  23. Locking a Mutex • If the “mutex M” is available and “thread T” needs it , should T lock it? t Mutex?? Mutex + Priority Inheritance?? pthread_mutex_lock pthread_mutex_unlock ecs251, fall 2007

  24. Risk for Locking a Mutex • If the “mutex M” is available and “thread T” needs it , should T lock it? Checking before Locking it!! We don’t know whether the high priority thread will occur in the next X seconds! But, does it matter? t pthread_mutex_lock t pthread_mutex_unlock ecs251, fall 2007

  25. “Checking” What?? ecs251, fall 2007

  26. pthread_mutex_lock pthread_mutex_unlock Mutex Priority Ceiling potential customers PC t t t Max priority A preventive action (could be unnecessary though) ecs251, fall 2007

  27. PC PC PC PC PC PC PC PC Priority CeilingShould I get it? thread t9 1 thread t2 ??? 4 thread t4 MaxPC value 2 4 locked unlocked ecs251, fall 2007

  28. PC PC PC PC PC PC PC PC Mutex/PIPGet it as long as it is available! thread t9 1 thread t2 YES 4 thread t4 MaxPC value 7 4 locked unlocked ecs251, fall 2007

  29. PC PC PC PC PC PC PC PC PCPNot so Fast thread t9 1 thread t2 NO 4 thread t4 MaxPC value 7 4 locked unlocked ecs251, fall 2007

  30. PC PC PC PC PC PC PC PC PCPNot so Fast thread t9 2 thread t2 NO 4 thread t4 MaxPC value 7 4 locked unlocked ecs251, fall 2007

  31. PC PC PC PC PC PC PC PC PCPHow about??? thread t2 2 thread t2 ?? 4 thread t4 MaxPC value 7 4 locked unlocked ecs251, fall 2007

  32. Are we sure about the claim of PCP? • A higher priority thread can be blocked at most once, in its life time,by one lower priority thread. • Deadlocks are prevented/avoided. • Try to find a “Counter Example” to show that PCP’s claim is FALSE!! ecs251, fall 2007

  33. s3 s2 s1 Critical Section Requirements(similar to 2PL) • Threads must lock and unlock in a “nested” or “pyramid” fashion: • Let L(S) = lock(S). • Let U(S) = unlock(S). • Example: L(s1);L(s2);L(s3);...;U(s3);U(s2);U(s1); ecs251, fall 2007

  34. Tasks 1 2 3 4 0 2 4 6 8 10 12 14 16 18 Preempted Executing Executing with Q locked Blocked Executing with V locked Ceiling-driven Indirectly Blocked ecs251, fall 2007

  35. Priority Inversion (12,6,8,17) 1 2 3 4 0 2 4 6 8 10 12 14 16 18 Preempted Executing Executing with Q locked Blocked Executing with V locked Ceiling-driven Indirectly Blocked ecs251, fall 2007

  36. Priority Inversion Area (12,6,8,17) 1 2 3 4 0 2 4 6 8 10 12 14 16 18 Preempted Executing Executing with Q locked Blocked Executing with V locked Ceiling-driven Indirectly Blocked ecs251, fall 2007

  37. Basic Priority Inheritance (9,12,14,17) Process 1 2 1 3 4 1 1 1 0 2 4 6 8 10 12 14 16 18 ecs251, fall 2007

  38. Priority Ceiling (7,12,14,17) 1 1 Process 1 2 3 4 2 2 2 1 1 0 2 4 6 8 10 12 14 16 18 locked ecs251, fall 2007

  39. Can we do better?? ecs251, fall 2007

  40. Priority Ceiling Emulation (6,12,14,17) 1 1 process d c 1 1 b a 1 1 1 1 0 2 4 6 8 10 12 14 16 18 ecs251, fall 2007

  41. “Kernel” Mutex OS Kernel User processes “No preemption in the Kernel mode” ecs251, fall 2007

  42. pthread_mutex_lock pthread_mutex_unlock PCP/PCE Mutex Obtain the PC value as my own priority Less context switching No Mutex queue!? PC ecs251, fall 2007

  43. Priority Ceiling Emulation • Each thread has a static (base) default priority assigned (perhaps by the deadline monotonic scheme). • Each resource has a static ceiling value defined, this is the maximum priority of the threads that use it. • A thread has a dynamic (active) priority that is the maximum of its own static priority and the ceiling values of any resources it has locked • As a consequence, a thread will only suffer a block at the very beginning of its execution • Once the thread starts actually executing, all the resources it needs must be free; if they were not, then some thread would have an equal or higher priority and the thread’s execution would be postponed ecs251, fall 2007

  44. Property #1 • A job J can be blocked by a lower priority job Jlow, only if the priority of J is no higher than the highest ceiling of all locked mutexes by lower priority jobs before J is initiated. ecs251, fall 2007

  45. Property #2 • Jj in a mutex Mj is preempted by Ji in another mutex Mi. Then, Jj can not inherit a priority higher than or equal to Ji until Ji completes. ecs251, fall 2007

  46. How? • Jsuperhigh is blocked by Jj (so Jj will inherit) • But, that mutex must not be locked yet. • Jj will never reach there before Ji finishes. ecs251, fall 2007

  47. Transitive Blocking ecs251, fall 2007

  48. Transitive Blocking • PCP prevents Transitive Blocking • J1, J2, J3 • J3 blocks J2, and J2 blocks J1 • J3 will inherit priority of J1, contradiction! ecs251, fall 2007

  49. Deadlock Free of PCP ecs251, fall 2007

  50. Deadlock Free of PCP • Circular waiting (circle must be two!) • Both of them must need both mutexes! ecs251, fall 2007

More Related