CS452 - Real-Time Programming - Spring 2009

Lecture 27 - Pathologies

1. Deadlock

2. Livelock (Deadly Embrace)

3. Critical Races

Critical race

Non-critical race

General solution

Races exist when more than one thing changes at once

It's better to design out races if you can.

A second description

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


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

Define `drastically'.


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

4. Performance

The hardest problem to solve


The hardest thing to get right

Problems with priority

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


  1. Too many tasks
  2. Not enough tasks

Layered abstraction are costly

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


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

Return to: