CS452 - Real-Time Programming - Spring 2008

Lecture 28 - Pathologies

Questions & Comment

  1. Statistical prediction
  2. Control theory


Not multually exclusive



  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


Livelock (Deadly embrace)

Resource contention


Kernel cannot easily detect this

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.

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


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


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

Performance Pathologies


  1. Priority inversion
  2. One resource, many clients


  1. Too many tasks
  2. Layered abstraction are costly

Server Structure

The Assassin

A unique task that is licensed to execute Destroy

The Doctor

Destory/Create is a common way to resolve malfunctions

Reset( ), an extra primitive, is a more efficient alternative.

Return to: