CS452 - Real-Time Programming - Winter 2015

Lecture 28 - Pathologies III

Public Service Annoucements

  1. Exam: 16.00 14 April to 18.30 15 April
  2. Milestone 2: 25 March, 2015
  3. Progress in the state of the train sets?
  4. Final demos. 6,7 April, 2015. Choice of format?
  5. Menu of possible lectures.


1. Deadlock

2. Livelock (Deadly Embrace)

3. Critical Races


  1. Explicit synchronization
  2. Gating is a technique of global synchronization
  3. Think about execution order when you are programming

Changes in performance of one task with respect to another often give rise to critical races.

4. Performance

The hardest problem to solve

In practice, how do you know you have performance problems? Here are a few sources of performance problems


The hardest thing to get right

Problems with priority

Priority changes the order of execution of your tasks, sometimes exposing a critical race. When this happens remember that the critical race was there all along, and will pop up later just when it's most incomvenience. Priority is useful for overall sensible design; it's a poor tool for trouble-shooting and bug-fixing.

  1. Priority inversion occurs when a high priority task blocks on a lower priority one. It can occur, for example, when a high priority server cannot proceed until it acquires information from a lower priority one. The higher priority server is then effectively at the lower priority.
  2. One resource, many clients. Our send queues are first-in, first-out. If the send queues are long a high priority client (a notifier, for example) waits in the send queue behind lower priority clients. (Of course, a long send queue is a sign of trouble ahead.)
  3. Tasks try to do too much. It is tempting to add functionality to a task rather than creating a new task. Each time you do this you increase the longest path from entering the task until leaving it. In fact, you can put your whole project into a single task -- it's happened before. Such a project does not get very high marks for design!


  1. Too many tasks ready at the same time.
  2. Layered abstractions are costly

Limited resources

  1. Bandwidth to the train controller
  2. Bandwidth to the terminal
  3. Any server with clients, workers, notifiers or couriers in its sendQ


  1. Turn on optimization, but be careful
  2. Turn on caches

Size & align calibration tables by size & alignment of cache lines

I think that this is stretching it.

Symptoms of performance problems

When you have a performance problem the hard part is recognizing that it is a performance problem because, when performance is bad the project crashes for a concrete reason, such as trains colliding. Looking at system performance is usually the last thing that is done.

Every one of the suggestions below has a problem: you must know what you expect to find in order to recognize that you are seeing something anomalous. Use your brain to estimate.

Return to: