CS452 - Real-Time Programming - Spring 2010

Lecture 29 - Reservations

Public Service Announcements

  1. Due date for Tracking 2
  2. Project plan


Something Essential that You Must Do

Design your reservation system before coding it.

Before coding your reservation system work it out on paper and make sure that it works for all the generic cases you can think of

  1. One train following another
  2. Two trains on a collision course
  3. There are one or more switches in the path

Common Multi-train Tracking Problems

  1. Two trains waiting on the same sensor report
  2. Spurious sensor report that a train is actually expecting.
  3. Permanently malfunctioning turn outs
  4. Permanently malfunctioning sensors
  5. Finding the trains at the beginning

Useful debugging

Common Reservation System Problems

  1. Reservations branch out ahead and cover a lot of the track
  2. Reservations are not released.
  3. Reservation leap-frogging

Useful debugging aids

  1. Insert/remove reservations by hand from the prompt
  2. Query reservations (and who holds them) from the prompt

Common Route-Finding/Following Bugs

  1. Train derails on turn out after changing direction
  2. Switch switches too late

Useful debugging aids

  1. Add/subtract switches, sections of track from graph by hand

Real-time Scheduling

Much real-time computing operates in an environment like the following

  1. Groups of sensors that are polled with fixed periodicity
  2. Sensor input triggers tasks which also run with fixed periodicity

Typical example, a group of sensors that returns

and a set of tasks that

Each time a sensor returns a new datum a scheduler runs

  1. makes ready any task that the data makes ready to run
  2. decides which of the ready tasks to schedule, and
  3. starts it running.

Your kernel can handle problems like this one pretty efficiently,

Cyclic Execution

Let's make a schedule

                                               A                                       A
  AC  BA    A C  A    A  C A    A B CA    A    C    A    AC B A    A C  A    A  C A    B
  |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |
      |                           |                         |                          |
   |          |          |          |          |          |          |          |
________________________________________________________________________________________________________ time

Because the times are integers the pattern repeats after a while.

Make it a little easier

  1. Make the complete pattern short by making sensor periods multiples of one another. If you can control sensor periods.
  2. Standardize the processing at each point
  3. Minimize the interaction between tasks
  4. Simple procedure
    1. Processing needed by task i is pi
    2. Share of CPU needed by pi is si = pi/ni
    3. s1 + s2 + s3 + ... < 1. Otherwise you must,
      • get a bigger processor, or
      • reduce the amount of computing needed
    4. Deadline for task i is di after the sensor report. si < di : otherwise
      • you always miss that deadline.
  5. Prove some theorems, such as Liu & Layland


Important assumptions

Main idea

Main result

Subsidiary result

Is this of any practical value?

Return to: