CS452 - Real-Time Programming - Fall 2011

Lecture 18 - Servers, Courier, Warehouse

Public Service Annoucements

  1. Due date of kernel 4 (Friday, 28 October)
  2. Saturday November 5, 11.00 to 13.00. Open house for high school students.

Anthropomorphic Programming

We all, even most programmers (!), have effective intuitions about human relations

Tasks are independent entities

Servers and Attendant Tasks

Why do servers need attendant tasks?

1. Proprietor with a Notifier

Proprietor `owns' a service, which usually means a resource. Proprietor actually does the work.

Kernel is handling hardware in this example


  1. Running
  2. Initializing
  3. Can only handle one event. Package several events into one


  1. Notifier is usually of higher priority than proprietor
  2. When, and how, do interrupts get turned on and/or cleared?
  3. Who coordinates hardware ownership?
  4. We have made proprietor code

    Why? It's something you might end up doing during your project

2. Using a Courier

Simplest is best






Transmit Proprietor Code


This gets you through a bottleneck where no more than two events come too fast.

Remember that all the calls provide error returns. You can/should use them for error recovery

Another possible arrangement for task creation

Another possible arrangement for initialization

Distributed gating

I am showing you collections of tasks implemented together because sets of related tasks is a level of organization above the individual task.

E.g., the decision to add a courier requires revision of code within the group, but not outside it.

3. Using a Warehouse

Add a warehouse between the courier and the notifier.

Notifier Code

Warehouse Code

Transmit Courier Code

Proprietor Code


This structure clears up most problems when a burst of requests to the server would leave the notifier waiting in a long sendQ..

Two issues:

  1. Handles bottlenecks of all sizes.

    Give a precise and quantitative definition of `bottleneck'.

  2. Server could be buffered on the other side

    Called a guard.

What this amounts to is

Server should be lean and hungry

always be receive blocked

Debugging Real-time Programs

The most common set of debugging tools used by experienced programmers is the oldest: printf, grep & stack trace.

Debugging real-time programs, at its base, is just the same as any other debugging, and just the same as empirical science.

  1. Gather data.
  2. Create a model that explains the data
  3. Test the model
  4. If the model is not correct, go to 1.
  5. Remember that the model is ALWAYS provisional: data collected later may invalidate it, no matter how much data has confirmed it.

But real-time programs are harder to debug. Very few programs are entirely free of critical races, which are the worst type of bug, lurking for weeks months or years in seemingly correct code, the appearing when innocuous, unconnected changes occur.


The memory contents are not wiped by reset. Some of the most difficult errors can be detected only by using the contents of memory after a reset.

On some types of exceptions RedBoot will attempt to connect with gdb. In such cases it writes a bunch of gibberish on the bottom of the monitor screen. Among that gibberish is the address of the instruction that caused the exception. Using the load map generated by the linker you can find

It is usually pretty easy to figure out which line of C source was responsible for the instruction.

Stack Trace

In single-threaded programs this is often the most useful tool.

What is the equivalent of a stack trace in a real-time multi-tasking environment?


What does it do?

How do you get it started?

Breakpoint is a special case of a particular sort of tool that is very common.

We need methods of getting information closer to real-time

Return to: