CS452 - Real-Time Programming - Spring 2010

Lecture 24 - Pathologies

Public Interest Announcements

  1. Demos
  2. How to give a demo

Pathologies

1. Deadlock

2. Livelock (Deadly Embrace)

3. Critical Races

Example

  1. Two tasks, A & B, at the same priority
  2. A is doing a lot of debugging IO
  3. B always reserves a section of track before A, and all is fine.
  4. Debugging IO is removed
  5. A reserves the section before B can get it, and execution collapses.
  6. Lower priority of A to the same level as C.
  7. Now C executes more slowly, and D gets a different resource before C .
  8. You shuffle priorities forever, eventually reverting to leave in the debugging IO.

Theory of relativity and the event horizon.

Symptoms

  1. Small changes in priorities change execution unpredictably, and drastically.
  2. Debugging output changes execution drastically.
  3. Changes in train speeds change execution drastically.

`Drastically' means chaos in both senses of the term

  1. Sense one: a small change in the initial conditions produces an exponentially growing change in the system
  2. Sense two: exercise for the reader.

Solutions

  1. Knowing what order you expect things to happen
  2. Explicit synchronization
  3. Gating is a technique of global synchronization

4. Performance

The hardest problem to solve

Priority

The hardest thing to get right

Problems with priority

  1. Priority inversion
  2. One resource, many clients
  3. Tasks try to do too much

Congestion

  1. Too many tasks
  2. Layered abstraction are costly
  3. Access to the train controller

Hardware

  1. Turn on optimization, but be careful
  2. Turn on caches
  3. Size & align calibration tables by size & alignment of cache lines

Reservations

Somebody has been doing something right for the last century. The answer is reservations.

Two Level Train Control

The two levels are completely independent of one another.

Upper Level

  1. Train asks despatcher for a route
  2. Despatcher provides a route that he/she thinks to be conflict free
  3. Train follows the route, reporting back to the despatcher as landmarks (sensors) are passed.

Lower Level

The lower level is encoded in the coloured lights you see along the track

Here's how it works

  1. Train asks reservation system for several blocks of track
  2. Reservation system grants the blocks if they are available

In practice this works as follows.

An Interesting Tit-bit That Doesn't Concern You

Real trains are long and sometimes occupy several blocks at once. How does the engineer know that the end of a train is clear of a switch?

Something Essential that You Must Do

Design your reservation system before coding it.

Before coding your reservation system work it out on paper and make sure that it works for all the generic cases you can think of

  1. One train following another
  2. Two trains on a collision course
  3. There are one or more switches in the path

Return to: