Assigment 1 Process Structure CS452/652 Train WYSE Clock Events Events Events Real-Time Notifier Notifier Notifier Programming 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 Status Commands 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 Send s. The diagram represents the steady state after all initialization is done. Reply s, 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 the various events, receives high-level train commands from tasks, g g notifiers, g serial servers, issues commands to track, and g g guards, and g the clock server. replies track information. g g 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 prompts user and requests sensor updates from train server, g g issues commands. gets current time, and g g displays updates on the WYSE. g 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. does GetTime() and g E.g., displays time on the WYSE. g 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 < p 2 < p 3 . ∴ 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. Ready & t p t 2 sends to t 3 and blocks. 1 1 Not Running t 1 sends to t 3 and blocks. > t 3 gets unblocked. t p Running 2 2 → one possibility is that t 2 waits while t 3 services > t 1 ’s request. t p Blocked 3 3 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 p Blocked But the possibility is enough to cause problems if the 1 1 possibility becomes a reality. > t p Blocked 2 2 > t p Running 3 3 t ’s request 1 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 Pathfinder, tasks communicate via an or uncontrolled. information bus. The bus management task, that moves data through g 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 The meterological data gathering task runs A HW interrupt causes the bus management task to g infrequently and is of low priority. This task uses wake up. the bus directly, by acquiring a semaphore, writing to the bus, and However, the meterological data gathering task holds f releasing the semaphore, the same semaphore the semaphore. the bus management task uses to access the bus, so as not to interfere with the information bus ∴ , the bus manager must wait until data gathering task f management task. gives up the semaphore. The communications task is of medium priority. g 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 Pathfinder, 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 If tasks t 1 , . . . , t n are SEND_BLOCKED or Use priority inheritance! 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 The next message received is from the highest priority Solution 1 SEND_BLOCKED task. Ready & Running t 1 p 1 p 3 t 1 Not Running > Ready & t 2 p t 2 Running 2 Not Running > t 3 p 3 t 3 Blocked 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 Implementation of these solutions requires: Solution 1 Solution 2 NOT order tasks by priority on any Send queue g t p 1 Blocked 1 OR > multiple queues per task, one for each priority g t 2 p Blocked 2 Also for Solution 1, also REPLY_BLOCKED tasks must be tracked. > Run t 3 p 3 p 3 Running t 2 ’s request t 1 ’s request = t 0 t 3 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”. Deadlock is a cyclic resource dependency. t t 2 1 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. t t 0 3 ∴ , None of t 0 , . .., t n − 1 can ever run. If each T i Send s before any T i Receive s, 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 potential deadlock. P 5 ∴ , in your applications, your steady-state diagram must P 4 be an acyclic graph, as is the graph at the beginning of this section of slides. P 3 If the process diagram is acyclic, it can be written as a hierarchy. P 4 P 1 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: Long-running tasks should have low priority. g Interactive tasks should have high priority. g 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 Serial Serial Clock Events Events Events p ServerT ServerW Server 4 < NotifierT NotifierW NotifierC Read Write Read Write p NotifierT NotifierW NotifierC GuardT GuardT GuardW GuardW 3 Serial Serial Time Clock ServerT ServerW Display Server < Train Time p Read Write Read Write 2 Server Display GuardT GuardT GuardW GuardW < Train User Track Track User Server Status p Commands 1 Status Commands 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 35 2007 Daniel M. Berry Real-Time Programming: Trains Pg. 36
Recommend
More recommend
