Presentation is loading. Please wait.

Presentation is loading. Please wait.

UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20071 Operating System Models ecs251 Fall 2007 : Operating System Models #3: Priority Inversion Dr. S.

Similar presentations


Presentation on theme: "UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20071 Operating System Models ecs251 Fall 2007 : Operating System Models #3: Priority Inversion Dr. S."— Presentation transcript:

1 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20071 Operating System Models 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

2 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20072 Unexpected Effects between two OS control mechanisms l Real-time priority scheduling –Responsiveness: if a higher priority thread appears, serve it asap. l 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”.

3 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20073 lock unlock 1 0 0 1 0 1 ::.::. 256 different priorities  64 scheduling classes RR

4 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20074 Real-Time Threads l Thread τ 1 L L L R x L l Thread τ 2 L L... L l Thread τ 3 L L L R x L... L l L: local CPU burst l R: resource required (Mutual Exclusion)

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

6 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20076Blocking τ 2 τ 3 t0t+3 t+4 R L L L R R L τ 1 t+6 L L L Blocked! L L L

7 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20077 The middle thread τ 2 τ 3 t0t+3 L L L R τ 1 L L L Blocked! t+2

8 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20078 Unbounded Priority Inversion τ 2 τ 3 t0t+3 t+253 RL L L R R L τ 1 t+254 L L L... L Blocked! t+2

9 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20079 Unbounded Priority Inversion τ 2-1 τ 3 t0t+3 t+2530 RL L L R R L τ 1 t+2 t+2540 L L L L Blocked! τ 2-2 τ 2-n L L

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

11 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200711 Priority Inheritance τ 2 τ 3 t0t+3t+4 L... L L L L R R L τ 1 t+2t+6 L L L R Blocked! dynamic  3 =  1 L... L

12 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200712 Priority Inheritance Protocols l 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

13 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200713 “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.” High priority: retrieval of data from shared memory Medium priority: communications task Low priority: thread collecting meteorological data

14 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200714 Basic Priority Inheritance l For each resource (semaphore), a list of blocked threads must be stored in a priority queue. l 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. l Priority inheritance is transitive; that is, if thread τ i blocks τ j and τ j blocks τ k, then τ i can inherit the priority of τ k.

15 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200715 Mutex Priority Inheritance pthread_mutex_lock pthread_mutex_unlock ttt waiting queue t priority

16 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200716 pthread_mutex_lock pthread_mutex_unlock M1M1 ttt waiting queue t priority pthread_mutex_lock pthread_mutex_unlock M2M2 ttt waiting queue priority

17 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200717 Transitive Priority pthread_mutex_lock pthread_mutex_unlock M1M1 ttt waiting queue t priority pthread_mutex_lock pthread_mutex_unlock M2M2 tt waiting queue t priority

18 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200718Problems l 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.

19 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200719 Blocking Chain Example l Task  1 : L R 2 L R 3 L R 4 L... L R n L,2(n-1) l Task  2 : L R 2 R 2, 2(n-2) l Task  3 : L R 3 R 3, 2(n-3) l Task  4 : L R 4 R 4, 2(n-4) l... l Task  n-1 : L R n-1 R n-1, 2(n-(n-1)) l Task  n : L R n R n, 2(n-n) starting time

20 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200720 Blocking Chain τ 2 τ n 0 L R n τ 1 RnRn R n L L R 2 R2R2 Blocked! L R 2 L Blocked!

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

22 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200722 PCP l How do we accomplish these goals intuitively?

23 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200723 Locking a Mutex l If the “mutex M” is available and “thread T” needs it, should T lock it? pthread_mutex_lock pthread_mutex_unlock t Mutex?? Mutex + Priority Inheritance??

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

25 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200725 “Checking” What??

26 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200726 Mutex Priority Ceiling pthread_mutex_lock pthread_mutex_unlock ttt potential customers PC Max priority A preventive action (could be unnecessary though)

27 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200727 Priority Ceiling Should I get it? PC locked unlocked MaxPC value thread t 2 ??? 4 thread t 4 1 thread t 9 2 4

28 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200728 Mutex/PIP Get it as long as it is available! PC locked unlocked MaxPC value thread t 2 YES 4 thread t 4 1 thread t 9 7 4

29 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200729 PCP Not so Fast PC locked unlocked MaxPC value thread t 2 NO 4 thread t 4 1 thread t 9 7 4

30 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200730 PCP Not so Fast PC locked unlocked MaxPC value thread t 2 NO 4 thread t 4 2 thread t 9 7 4

31 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200731 PCP How about??? PC locked unlocked MaxPC value thread t 2 ?? 4 thread t 4 2 thread t 2 7 4

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

33 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200733 Critical Section Requirements (similar to 2PL) l Threads must lock and unlock in a “nested” or “pyramid” fashion: –Let L(S) = lock(S). –Let U(S) = unlock(S). –Example: L(s 1 );L(s 2 );L(s 3 );...;U(s 3 );U(s 2 );U(s 1 ); s 1 s 2 s 3

34 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200734 4 3 2 1 024681012141618 Executing Executing with Q locked Preempted Executing with V locked Blocked Tasks Ceiling-driven Indirectly Blocked

35 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200735 4 3 2 1 024681012141618 Executing Executing with Q locked Preempted Executing with V locked Blocked Priority Inversion (12,6,8,17) Ceiling-driven Indirectly Blocked

36 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200736 4 3 2 1 024681012141618 Executing Executing with Q locked Preempted Executing with V locked Blocked Priority Inversion Area (12,6,8,17) Ceiling-driven Indirectly Blocked

37 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200737 111 4 3 2 1 024681012141618 Process 1 Basic Priority Inheritance (9,12,14,17)

38 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200738 2212 4 3 2 1 024681012141618 Process 1 Priority Ceiling (7,12,14,17) 11 locked

39 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200739 Can we do better??

40 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200740 1111 a b c d 024681012141618 process 11 Priority Ceiling Emulation (6,12,14,17) 11

41 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200741 “Kernel” Mutex OS Kernel User processes “No preemption in the Kernel mode”

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

43 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200743 Priority Ceiling Emulation l Each thread has a static (base) default priority assigned (perhaps by the deadline monotonic scheme). l Each resource has a static ceiling value defined, this is the maximum priority of the threads that use it. l 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 l As a consequence, a thread will only suffer a block at the very beginning of its execution l 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

44 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200744 Property #1 l A job J can be blocked by a lower priority job J low, 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.

45 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200745 Property #2 l J j in a mutex M j is preempted by J i in another mutex M i. Then, J j can not inherit a priority higher than or equal to J i until J i completes.

46 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200746 How? l J superhigh is blocked by J j (so J j will inherit) l But, that mutex must not be locked yet. l J j will never reach there before J i finishes.

47 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200747 Transitive Blocking

48 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200748 Transitive Blocking l PCP prevents Transitive Blocking l J 1, J 2, J 3 l J 3 blocks J 2, and J 2 blocks J 1 l J 3 will inherit priority of J 1, contradiction!

49 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200749 Deadlock Free of PCP

50 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200750 Deadlock Free of PCP l Circular waiting (circle must be two!) l Both of them must need both mutexes!

51 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200751 Property #3 l J i can be blocked by J low for at most one duration of mutex.

52 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200752 One duration block l J i can be blocked once for all J low ’s.

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

54 UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 200754 Summary l Priority Inversion l Basic Priority Inheritance l Priority Ceiling –Upgraded when a higher priority task (might not be the same as the ceiling value) is blocked due to the Ceiling value l Priority Ceiling Emulation –Immediately upgraded to the ceiling value after obtaining the lock


Download ppt "UCDavis, ecs251 Fall 2007 10/23/2007ecs251, fall 20071 Operating System Models ecs251 Fall 2007 : Operating System Models #3: Priority Inversion Dr. S."

Similar presentations


Ads by Google