CS452 - Real-Time Programming - Fall 2008

Lecture 21 - Pathologies


Questions & Comment

  1. next Monday

Pathologies

1. Deadlock

2. Livelock (Deadly Embrace)

3. Critical Races

Theory of relativity and the event horizon

One task tests a condition

Another task tests the same condition

And the two actions are incompatible.

That is, information about the action of the first task did not spread instantaneously:

Concrete example.

Engineer sends to switchDetective

Before switchDetective does RegisterAs, a second Engineer sends to switchDetective

Each switchDetective, or its courier, does Put and Get to find out about switches.

This is only a little bad, you probably won't even notice it, except your performance will be bad.

But it can be much worse

Symptoms

  1. Small changes in priorities change execution unpredictably, and drastically.
  2. Debugging output changes execution drastically.

Solutions

  1. A protocol for using the name server
  2. At initialization it's a programming bug,

4. Performance

Remote Delay

Priority

  1. Priority inversion
  2. One resource, many clients

Congestion

  1. Too many tasks

Layered abstraction are costly

e.g. Notifier -> SerialServer -> InputAccumulater -> Parser -> TrackServer


Practical Control

Data

What levers do you have?

What do you need to control?

What input do you get

What other data do you have?

How do you find out where the train is?

  1. On a sensor trigger know that a train triggered the sensor at time t

    Must find out which train

  2. After a sensor trigger we can estimate position

Velocity Estimation

This is an empirical problem.

That is,

The past is a good predictor of the future. Therefore conclude that

But there is error in this measurement, from three possible sources

  1. screw-up errors
    1. throw them out
    2. sometimes you can eliminate them
  2. random errors
  3. systematic errors

How useful is yesterday's data?

Eliminating screw-up errors

Redefine the track

For example, if a sensor malfunctions frequently

Transforming random errors

You can sometimes identify patterns in what you think are random errors

Projecting out systematic errors

Subdivide the data.


Return to: