CS452 - Real-Time Programming - Fall 2009

Lecture 25 - Pathologies

Reminders


Calibration

Practical Issues

You might want to consider

  1. Using floating point for calculation. The easiest way to do this is to have a single calibration task that

    If more than one task uses fixed point you must change your context switch if any access to the floating point processor is non-atomic.

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

    but only if access speed is a problem.

  4. Each train has a built-in velocity profile used when the train slows or stops.

    You can create your own profile by a succession of speed commands.


Pathologies

1. Deadlock

One or more tasks will never run again. For example

  1. Task sends to itself (local: rest of system keeps running, task itself will never run)
  2. Every task does Receive( ) (global: nothing is running)
  3. Cycle of tasks sending around the cycle (local: other tasks keep running)

Kernel can detect such things

Possible send-blocking can be detected at compile time

Solutions

2. Livelock (Deadly Embrace)

Usually occurs in the context of resource contention. For example

Kernel(s) cannot easily detect livelock

Possible solutions

  1. both resources in one proprietor
  2. global order on resource requests
  3. ethernet algorithm

Could consider this a form of critical race.

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. Explicit synchronization
  2. 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

Layered abstraction are costly

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

Hardware

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

Return to: