Assigment 1 Process Structure CS452/652 Train WYSE Clock Events Events Events Real-Time Programming Notifier Notifier Notifier Serial Serial Time Clock Course Notes Server Server Display Server Read Write Read Write Guard Guard Guard Guard Daniel M. Berry, Cheriton School of Computer Science University of Waterloo Train User Track Server Commands Status 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 1 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 2 Process Steady State This graph shows only Sends. The diagram represents the steady state after all initialization is done. Replys, in the opposite directions are implied; so it is not necessary to show them. ∴, communication during initialization, e.g. with the name server, is not included. Also, later, a potential deadlock detection algorithm depends on having only Send arcs. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 3 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 4 You Already Know Train Server You already know about: The train server g the various events, g receives high-level train commands from tasks, g noti®ers, g serial servers, g issues commands to track, and g guards, and g the clock server. g replies track information. We talk about what is new. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 5 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 6 User Commands Track Status The user commands process The track status process g prompts user and g requests sensor updates from train server, g issues commands. g gets current time, and g displays updates on the WYSE. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 7 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 8 Time Display Priority Inversion The time display process Priority inversion (PI) occurs when a task is forced to wait on another task of lower priority. g does GetTime() and E.g., g displays time on the WYSE. Task t 1 with priority p 1, ready Task t 2 with priority p 2, ready Task t 3 with priority p 3, ready p 1 <p2 <p3. ∴ t 3 is running. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 9 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 10 Priority Inversion, Cont'd Scenario 1 Two different scenarios. t 3 sends to t 1 → t 3 waits while t 2 runs 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 11 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 12 Scenario 1, Cont'd Scenario 2 t 3 is blocked. t Ready & p 1 Not Running 1 t 2 sends to t 3 and blocks. > t 1 sends to t 3 and blocks. t gets unblocked. t2 Running p2 3 → one possibility is that t 2 waits while t 3 services > t 1's request. t3 Blocked p3 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 13 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 14 Scenario 2, Cont'd Scenarios Only Possible Each of these scenarios is possible, not guaranteed. t Blocked p 1 1 But the possibility is enough to cause problems if the possibility becomes a reality. > t2 Blocked p2 > t3 Running p3 t1's request 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 15 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 16 Duration of an Inversion Real-Life Example of PI The duration of a priority inversion can be unbounded In the Mars Path®nder, tasks communicate via an or uncontrolled. information bus. g The bus management task, that moves data through the bus, is of high priority. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 17 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 18 Real-Life Example of PI, Cont'd Problematic Scenario g The meterological data gathering task runs A HW interrupt causes the bus management task to infrequently and is of low priority. This task uses wake up. the bus directly, by f acquiring a semaphore, writing to the bus, and However, the meterological data gathering task holds releasing the semaphore, the same semaphore the semaphore. the bus management task uses to access the bus, f so as not to interfere with the information bus ∴, the bus manager must wait until data gathering task management task. gives up the semaphore. g The communications task is of medium priority. Priority inversion! These priority assignments make sense. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 19 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 20 Problematic Scenario, Cont'd Problematic Scenario, Cont'd This priority inversion is normally not a problem. For the Mars Path®nder, this reset is OK and does not cause any real problem because there is no state to However, if the medium priority task gets scheduled remember; it always sends just the current data. before the semaphore is released, then the bus management task cannot run. For your trains software, there is state, namely the setting of all switches, the location of all trains, etc. The implemented solution: Eventually a watchdog task detects that the bus manager has not run for some time, So a reset is not an acceptable solution to priority concludes that there is a problem, and resets the inversion. system. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 21 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 22 How to Fix Priority Inversion Solving Scenario 1 Use priority inheritance! If tasks t 1 , ...,t n are SEND_BLOCKED or REPLY_BLOCKED on t 0, That is, cause a task t to temporarily inherit a higher priority from the higher priority task that depends on t. actualPriority(t 0)=MAX (assignedPriority (t i)) 0≤i≤n I.e., promote t 0 to have the highest of the priorities of the tasks waiting on t 0. Then a medium priority task cannot preempt t 0. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 23 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 24 Solving Scenario 1, Cont'd Solving problem 2 Solution 1 The next message received is from the highest priority SEND_BLOCKED task. t Ready & p p t Running 1 Not Running 1 3 1 Ready & t2 Running p2 t2 Not Running >> t3 Blocked p3 t3 Blocked 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 25 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 26 Solving Scenario 2, Cont'd Implementation Solution 1 Solution 2 Implementation of these solutions requires: NOT g t1 Blocked p1 order tasks by priority on any Send queue OR g multiple queues per task, one for each priority t Blocked p 2 2 Also for Solution 1, also REPLY_BLOCKED tasks must be tracked. >> t Running p p Run 3 3 3 t 's request t1's request 2 t0 = t3 first. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 27 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 28 Deadlock! Cyclic Resource Dependency Note that priority inheritance prevents priority A cyclic resource dependency is called also ªa cyclic inversion, but not deadlock send patternº. t t Deadlock is a cyclic resource dependency. 1 2 Among tasks t 0 ,...,t n − 1, each task t i holds a resource that is needed by t (i + 1) mod n to proceed. t0 t3 ∴, None of t 0 ,...,t n − 1 can ever run. If each T i Sends before any T i Receives, the tasks deadlock. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 29 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 30 Deadlock, Cont'd Hierarchy A cycle in the steady-state process diagram indicates a P potential deadlock. 5 ∴, in your applications, your steady-state diagram must P be an acyclic graph, as is the graph at the beginning of 4 this section of slides. P3 If the process diagram is acyclic, it can be written as a hierarchy. P4 P1 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 31 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 32 After Making the Hierarchy Hierarchy for Assignment 1 Assign higher priorities to process that are higher in the Let's build the hierarchy for the suggested process graph. structure for Assignment 1. This method assumes that processes are usually First, make each task name unique. blocked: g Long-running tasks should have low priority. g Interactive tasks should have high priority. 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 33 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 34 Hierarchy for Assignment 1, Cont'd Hierarchy for Assignment 1, Cont'd Train WYSE Clock Events Events Events Serial Serial Clock p ServerT ServerW Server 4 < NotifierT NotifierW NotifierC Read Write Read Write NotifierW NotifierC p NotifierT GuardT GuardT GuardW GuardW 3 Serial Serial Time Clock ServerT ServerW Display Server < Train Time p Read Write Read Write Server Display 2 GuardT GuardT GuardW GuardW < Train User Track Server Commands Status Track User p Status Commands 1 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 35 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 36 OS Design Principles Monolithic Two choices: g Entire OS runs in kernel space. g The OS is one big program. g Monolithic g Microkernel User Applications Space Kernel Kernel = OS Space 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 37 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 38 Monolithic, Cont'd Microkernel g The OS is easy to get wrong! g The kernel, consisting of only memory management (GDT), IPC, scheduling, is small. g If one OS module fails, the entire OS may go down.