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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 1 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 3 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 5 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 7 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

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 9 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 11 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 13 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 15 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 17 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 19 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 21 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 23 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 25 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 27 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 29 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 31 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 33 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 35 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  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 37 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. g Non-essential OS services are implemented as user-space programs, called servers, which include g But, the OS is very ef®cient, once the bugs are ®le systems, device drivers, and networking. worked out; less communication overhead

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 39 Real-Time Programming: Trains Pg. 40 Microkernel, Cont’d Microkernel, Cont’d

g If an OS service fails, it can be restarted without Applications User bringing down the kernel. Space g Performance depends on Servers f fast IPC and f fast context switching. Kernel Kernel g Server development is easier than kernel Space development g The OS is more secure, in the sense that less of the OS has access to all of memory.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 41 Real-Time Programming: Trains Pg. 42

Microkernel, Cont’d Application Code

Examples: The same design question can be applied to application code: Mach, QNX, Minix, AmigaOS ªOne task or several?º First Microkernel OS, that happened also to be real time: or

D.R. Cheriton, M.A. Malcom, L.S. Melen, G.R. Sager, ªWhy not make the application a big loop polling the ªThoth, A Portable Real-Time Operating System, user's input?º Communications of the ACM, 22:2, pp. 105±115, February 1975.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 43 Real-Time Programming: Trains Pg. 44 Task Abstraction Task Abstraction, Cont’d

A task An individual task is easy to understand; it g is sequential, g is an independent autonomous agent and g is deterministic, g executes independently, g can be a basic application structuring unit. g has its own address space, and g interacts with other tasks through visible interfaces.

The behavior of a server is speci®ed by the messages it receives and the reply it generates in response to each received message.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 45 Real-Time Programming: Trains Pg. 46

E.g., the clockServer is speci®ed by the semantics of Multiprocess Structuring its methods: Multiprocess structuring can be done using stereotyped g Delay, team structures and team members, ¼

g GetTime, and Sort of process patterns

g DelayUntil.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 47 Real-Time Programming: Trains Pg. 48 Task Stereotypes Server Stereotypes

g Servers g proprietor Ð synchronizes accesses to a resource, e.g., serial server, for, e.g. video display g Workers g distributor Ð acquires data, stores, and distributes them, e.g., state of track g Clients g administrator Ð assigns and monitors work done by other tasks, e.g., managing a pool of worker tasks

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 49 Real-Time Programming: Trains Pg. 50

Worker Stereotypes Client Stereotypes

g noti®er Ð monitors events g usually application speci®tag">c Ð drives the high-level application logic. g courier Ð moves data from server to server

g guard Ð controls accesses to a server

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 51 Real-Time Programming: Trains Pg. 52 Proprietor Proprietor, Cont’d

According to Cheriton, a proprietor manages a resource The details of Service distinguishes one proprietor and provides synchronous access, using mutual from another. exclusion

Proprietor(){ Initialize(); while(1){ (pid,request) ← Receive(); Reply(pid,Service(pid,request)); } }

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 53 Real-Time Programming: Trains Pg. 54

Proprietor, Cont’d Adminstrator

The train command proprietor According to Morven Gentleman, an administrator

g deals with one client at a time and g is a generalized proprietor, g may send messages to other servers. g may spawn workers, or agents, to handle requests, g may prioritize requests, so that service is not

C1 always FIFO, and g can use parameters in the clients' messages to . determine which client's request to process next. . train serial . command server . .

Cn

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 55 Real-Time Programming: Trains Pg. 56 Adminstrator, Cont’d Consider This Situation

C1 C1' C1 Worker1

. . . . . ? . server1 server2 . . . . . Administrator ......

Cn Cm' Cn Workern

Server 1 needs to send data to Server 2.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 57 Real-Time Programming: Trains Pg. 58

Situation, Cont’d Solution

g If Server 1 sends to Server 2, then Server 1 is Have a courier task. SEND_BLOCKED. ∴, Server 1 cannot receive

from a client. C1 C1' g Same for Server 2 . . . . Send . server1 courier server2 . In general, servers should not ever do . . . . .

Cn Cm'

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 59 Real-Time Programming: Trains Pg. 60 Courier Generic Courier

A courier moves data from one speci®ed server, named CreateCourier(pid) Ð an OS service, and is optional. by pid0, to another speci®ed server, named by pid1. This does Courier(MyPid(),pid). So it is a worker.

Courier(pid0,pid1){ while(1){ Send(pid0,msg1,msg0); Send(pid1,msg0,msg1); } }

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 61 Real-Time Programming: Trains Pg. 62

Other Worker Stereotypes Suggest Train Application

Noti®ers Structure

Guards As suggested by Gentleman:

For more details, see W.M. Gentleman, ªMessage Passing Betwen Sequential Processors: the Reply Primitive and the Administrator Conceptº, Software Practice & Experience, 11, pp.436±466, 1981.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 63 Real-Time Programming: Trains Pg. 64 Train Application Structure Structure, Cont’d

Verifying that this graph as no cycles is left as an Engineer exercise for the student! Timer Timer (Train 0)

. What are the processes that have no outgoing arcs? . . Sensor Sensor Track As a matter of fact, it has no cycles! Notifier Admin'or Courier Admin'or

Engineer (Train n)

Manual Control Interface Signal Driver

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 65 Real-Time Programming: Trains Pg. 66

Two Administrators Other Tasks

g Track Administrator mangages current state of the g Timer sends a message every k ticks. track and the positions of the trains. g Engineer computes the next objective for one train, either move forward on completion of a subgoal or g Sensor Administrator summarizes and validates complete an alternative on failure. sensor information; it interprets each sensor hit as evidence of a train's position, as spurious, or as g Control Signal Driver sends commands to the track. indicating hardware failure. g Manual Interface passes on user commands.

 2007 Daniel M. Berry  2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 67 Real-Time Programming: Trains Pg. 68

Multiple Administrators

g increases modularity and

g decreases wait time for time-critical clients, e.g. Noti®ers.

 2007 Daniel M. Berry

Real-Time Programming: Trains Pg. 69