CS452/652 Train WYSE Clock Events Events Events Real-Time - - PowerPoint PPT Presentation

▶
cs452 652
SMART_READER_LITE
LIVE PREVIEW

CS452/652 Train WYSE Clock Events Events Events Real-Time - - PowerPoint PPT Presentation

Oct 11, 2022 127 likes •316 views

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

slide-1
SLIDE 1

CS452/652 Real-Time Programming Course Notes

Daniel M. Berry, Cheriton School of Computer Science University of Waterloo

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 1

Assigment 1 Process Structure

Serial Guard Write Commands User Server Train Guard Read Guard Write Server Serial Notifier Server Guard Read Events Clock Events WYSE Events Train Status Track Notifier Server Clock Display Time Notifier

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 2

Process

This graph shows only Sends. Replys, in the opposite directions are implied; so it is not necessary to show them. Also, later, a potential deadlock detection algorithm depends on having only Send arcs.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 3

Steady State

The diagram represents the steady state after all initialization is done. ∴, communication during initialization, e.g. with the name server, is not included.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 4
slide-2
SLIDE 2

You Already Know

You already know about: g the various events, g notifiers, g serial servers, g guards, and g the clock server. We talk about what is new.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 5

Train Server

The train server g receives high-level train commands from tasks, g issues commands to track, and g replies track information.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 6

User Commands

The user commands process g prompts user and g issues commands.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 7

Track Status

The track status process g requests sensor updates from train server, g gets current time, and g displays updates on the WYSE.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 8
slide-3
SLIDE 3

Time Display

The time display process g does GetTime() and g displays time on the WYSE.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 9

Priority Inversion

Priority inversion (PI) occurs when a task is forced to wait on another task of lower priority. E.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. 10

Priority Inversion, Cont’d

Two different scenarios.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 11

Scenario 1

t 3 sends to t 1 → t 3 waits while t 2 runs

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 12
slide-4
SLIDE 4

Scenario 1, Cont’d

> >

3

p

3

t

2

t

1

t

1

p

2

p

Not Running Ready & Blocked Running

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 13

Scenario 2

t 3 is blocked. t 2 sends to t 3 and blocks. t 1 sends to t 3 and blocks. t 3 gets unblocked. → one possibility is that t 2 waits while t 3 services t 1’s request.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 14

Scenario 2, Cont’d

’s request 1

t

Running Blocked

> >

3

p

3

t

2

t

1

p

2

p

Blocked 1

t

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 15

Scenarios Only Possible

Each of these scenarios is possible, not guaranteed. But the possibility is enough to cause problems if the possibility becomes a reality.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 16
slide-5
SLIDE 5

Duration of an Inversion

The duration of a priority inversion can be unbounded

  • r uncontrolled.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 17

Real-Life Example of PI

In the Mars Pathfinder, tasks communicate via an 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. 18

Real-Life Example of PI, Cont’d

g The meterological data gathering task runs infrequently and is of low priority. This task uses the bus directly, by f acquiring a semaphore, writing to the bus, and releasing the semaphore, the same semaphore the bus management task uses to access the bus, f so as not to interfere with the information bus management task. g The communications task is of medium priority. These priority assignments make sense.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 19

Problematic Scenario

A HW interrupt causes the bus management task to wake up. However, the meterological data gathering task holds the semaphore. ∴, the bus manager must wait until data gathering task gives up the semaphore. Priority inversion!

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 20
slide-6
SLIDE 6

Problematic Scenario, Cont’d

This priority inversion is normally not a problem. However, if the medium priority task gets scheduled before the semaphore is released, then the bus management task cannot run. The implemented solution: Eventually a watchdog task detects that the bus manager has not run for some time, concludes that there is a problem, and resets the system.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 21

Problematic Scenario, Cont’d

For the Mars Pathfinder, this reset is OK and does not cause any real problem because there is no state to remember; it always sends just the current data. For your trains software, there is state, namely the setting of all switches, the location of all trains, etc. So a reset is not an acceptable solution to priority inversion.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 22

How to Fix Priority Inversion

Use priority inheritance! That is, cause a task t to temporarily inherit a higher priority from the higher priority task that depends on t.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 23

Solving Scenario 1

If tasks t 1 , . . . ,t n are SEND_BLOCKED or REPLY_BLOCKED on t 0, actualPriority(t 0) =

0≤i≤n

MAX (assignedPriority (t i)) 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. 24
slide-7
SLIDE 7

Solving Scenario 1, Cont’d

p1

> >

Solution 1

Running Blocked

t1 t2 t3

Blocked

t1 t2 t3

Running 2

p3 p3

Ready & Not Running Ready & Not Running

p

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 25

Solving problem 2

The next message received is from the highest priority SEND_BLOCKED task.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 26

Solving Scenario 2, Cont’d

p1

> >

Blocked Running

t1’s request

Solution 1 Solution 2

= t0 t3

NOT Run first. ’s request

2

t3 p3 p3

1

t t2 t2

Blocked

p

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 27

Implementation

Implementation of these solutions requires: g

  • rder tasks by priority on any Send queue

OR g multiple queues per task, one for each priority Also for Solution 1, also REPLY_BLOCKED tasks must be tracked.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 28
slide-8
SLIDE 8

Deadlock!

Note that priority inheritance prevents priority inversion, but not deadlock Deadlock is a cyclic resource dependency. 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. ∴, None of t 0 ,...,t n − 1 can ever run.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 29

Cyclic Resource Dependency

A cyclic resource dependency is called also “a cyclic send pattern”.

3

t

2

t

1

t t

If each T i Sends before any T i Receives, the tasks deadlock.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 30

Deadlock, Cont’d

A cycle in the steady-state process diagram indicates a potential deadlock. ∴, in your applications, your steady-state diagram must be an acyclic graph, as is the graph at the beginning of this section of slides. If the process diagram is acyclic, it can be written as a hierarchy.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 31

Hierarchy

P5 P4 P P4 P1

3

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 32
slide-9
SLIDE 9

After Making the Hierarchy

Assign higher priorities to process that are higher in the graph. This method assumes that processes are usually 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

Hierarchy for Assignment 1

Let’s build the hierarchy for the suggested process structure for Assignment 1. First, make each task name unique.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 34

Hierarchy for Assignment 1, Cont’d

Serial GuardW Write Commands User Server Train GuardW Read GuardT Write ServerT Serial NotifierT ServerW GuardT Read Events Clock Events WYSE Events Train Status Track NotifierC Server Clock Display Time NotifierW

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 35

Hierarchy for Assignment 1, Cont’d

ServerW Serial ServerT Serial GuardT Read NotifierT Clock Display Time Commands User Status Track Server Train GuardT Write NotifierW GuardW Read GuardW Write NotifierC Server

< < <

1

p

2

p

3

p

4

p

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 36
slide-10
SLIDE 10

OS Design Principles

Two choices: g Monolithic g Microkernel

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 37

Monolithic

g Entire OS runs in kernel space. g The OS is one big program.

Applications Kernel = OS User Space Kernel Space

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 38

Monolithic, Cont’d

g The OS is easy to get wrong! g If one OS module fails, the entire OS may go down. g But, the OS is very efficient, once the bugs are worked out; less communication overhead

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 39

Microkernel

g The kernel, consisting of only memory management (GDT), IPC, scheduling, is small. g Non-essential OS services are implemented as user-space programs, called servers, which include file systems, device drivers, and networking.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 40
slide-11
SLIDE 11

Microkernel, Cont’d

Kernel Space User Space Applications Kernel Servers

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 41

Microkernel, Cont’d

g If an OS service fails, it can be restarted without bringing down the kernel. g Performance depends on f fast IPC and f fast context switching. g Server development is easier than kernel 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 Real-Time Programming: Trains

  • Pg. 42

Microkernel, Cont’d

Examples: Mach, QNX, Minix, AmigaOS First Microkernel OS, that happened also to be real time: D.R. Cheriton, M.A. Malcom, L.S. Melen, G.R. Sager, “Thoth, A Portable Real-Time Operating System, Communications of the ACM, 22:2, pp. 105–115, February 1975.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 43

Application Code

The same design question can be applied to application code: “One task or several?”

  • r

“Why not make the application a big loop polling the user’s input?”

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 44
slide-12
SLIDE 12

Task Abstraction

A task g is an independent autonomous agent and g can be a basic application structuring unit.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 45

Task Abstraction, Cont’d

An individual task is easy to understand; it g is sequential, g is deterministic, g executes independently, g has its own address space, and g interacts with other tasks through visible interfaces. The behavior of a server is specified by the messages it receives and the reply it generates in response to each received message.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 46

E.g., the clockServer is specified by the semantics of its methods: g Delay, g GetTime, and g DelayUntil.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 47

Multiprocess Structuring

Multiprocess structuring can be done using stereotyped team structures and team members, … Sort of process patterns

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 48
slide-13
SLIDE 13

Task Stereotypes

g Servers g Workers g Clients

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 49

Server Stereotypes

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

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 50

Worker Stereotypes

g notifier — monitors events g courier — moves data from server to server g guard — controls accesses to a server

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 51

Client Stereotypes

g usually application specific — drives the high-level application logic.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 52
slide-14
SLIDE 14

Proprietor

According to Cheriton, a proprietor manages a resource and provides synchronous access, using mutual exclusion Proprietor(){ Initialize(); while(1){ (pid,request) ← Receive(); Reply(pid,Service(pid,request)); } }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 53

Proprietor, Cont’d

The details of Service distinguishes one proprietor from another.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 54

Proprietor, Cont’d

The train command proprietor g deals with one client at a time and g may send messages to other servers.

server serial command train . . . . . Cn C1

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 55

Adminstrator

According to Morven Gentleman, an administrator g is a generalized proprietor, g may spawn workers, or agents, to handle requests, g may prioritize requests, so that service is not always FIFO, and g can use parameters in the clients’ messages to determine which client’s request to process next.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 56
slide-15
SLIDE 15

Adminstrator, Cont’d

. . . . . . . . . . . . . . . . . . . C1 Cn Administrator Workern Worker1 .

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 57

Consider This Situation

? server2 server1 . . . . . Cm’ C1’ . . . . C1 Cn .

Server 1 needs to send data to Server 2.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 58

Situation, Cont’d

g If Server 1 sends to Server 2, then Server 1 is SEND_BLOCKED. ∴, Server 1 cannot receive from a client. g Same for Server 2 In general, servers should not ever do Send.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 59

Solution

Have a courier task.

. . . . C1’ Cm’ . . . . . server2 courier server1 . C1 Cn

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 60
slide-16
SLIDE 16

Courier

A courier moves data from one specified server, named by pid0, to another specified server, named by pid1. So it is a worker. Courier(pid0,pid1){ while(1){ Send(pid0,msg1,msg0); Send(pid1,msg0,msg1); } }

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 61

Generic Courier

CreateCourier(pid) — an OS service, and is optional. This does Courier(MyPid(),pid).

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 62

Other Worker Stereotypes

Notifiers Guards 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 Real-Time Programming: Trains

  • Pg. 63

Suggest Train Application Structure

As suggested by Gentleman:

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 64
slide-17
SLIDE 17

Train Application Structure

. .

Timer

.

Notifier Sensor Admin’or Sensor Interface Manual Control Signal Driver Admin’or Track Engineer (Train n) Courier Timer Engineer (Train 0)

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 65

Structure, Cont’d

Verifying that this graph as no cycles is left as an exercise for the student! What are the processes that have no outgoing arcs? As a matter of fact, it has no cycles!

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 66

Two Administrators

g Track Administrator mangages current state of the track and the positions of the trains. g Sensor Administrator summarizes and validates sensor information; it interprets each sensor hit as evidence of a train’s position, as spurious, or as indicating hardware failure.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 67

Other Tasks

g Timer sends a message every k ticks. g Engineer computes the next objective for one train, either move forward on completion of a subgoal or complete an alternative on failure. g Control Signal Driver sends commands to the track. g Manual Interface passes on user commands.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 68
slide-18
SLIDE 18

Multiple Administrators

g increases modularity and g decreases wait time for time-critical clients, e.g. Notifiers.

 2007 Daniel M. Berry Real-Time Programming: Trains

  • Pg. 69