CS452 - Real-Time Programming - Fall 2011

Lecture 34 - Cyclic Execution

Public Service Annoucements

  1. Final demo: Tuesday, 6 December, 2011; Wednesday, 7 December, 2011
  2. Final exam: 10.30, Friday, 9 December, 2011 to 13.30, Saturday, 10 December, 2011.

Cyclic Execution


In continuous operation for 34 years, 2 months, 25 days.

It was designed to have a three-year lifetime!


6000 word instruction and scratch data memory

62,500 Kbyte digital tape recorder for storage of sensor data

System Software

Cyclic executive

Cyclic Execution

  1. Clock ticks
  2. Starts executing, in priority order, programs that are ready to run.
  3. At end of programs, wait until the clock ticks, then go to 2.
  4. If clock ticks before end of programs, then report fault to earth and go to 2.
  5. Cycle can be interrupted by receiving input from earth that tells it to jump to boot mode.

This is an abstract description: with so little memory it is essential to squeeze out every word.

Most of the programs have the form

  1. If input from X, then do A.

We are back at the beginning of the course, but we know much more now.

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 finite schedule that repeats

                                               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

If 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? Yes, otherwise I wouldn't bother teaching it.

Your project

If your project is correct, but resource limited, the critical instant for the limiting resource is the place where your project fails. For example.

Your job

Think about how a mobile telephone works.

When you want to play a game, consult your calendar, browse the internet, etc you want asynchronous response from the phone

This sounds easy. Why is it hard in practice?

Apps are better if they can install tasks on the cyclic executive


Return to: