CS452 - Real-Time Programming - Spring 2012

Lecture 33 - Cyclic Execution

Public Service Annoucements

  1. Final exam date: 9.00 August 7 to 11.30 August 9
  2. Final demos: 26 August & 27 August

Software

Server with clients & a worker

Occam2

FOREVER
  ALT
    from.client ? request && workerfree
      SEQ
        workerfree = false
        to.worker ! request
    from.worker ? result
      SEQ
        workerfree = true
        to.client ! result

Go

FOREVER {
    select {
    case request <- from.client && workerfree
        workerfree = false
        request.data -> to.worker
    case result <- from.worker
        result -> request.chan
    {
}

Timing out

Occam2

PAR
  SEQ
    sleep( delay )
    timeout ! true
  ALT
    in.data ? data
      // respond to data
    timeout ? now
      // data timed out

Go

timeout := make( chan bool )
go func( ) {
  time.Sleep( delay )
  timeout <- true
}( )
select {
case <- ch:
  // data available
case <- timeout:
  // read timed out
}

Cyclic Execution

Voyageur

In continuous operation for 34 years, 10 months, 7 days.

It was designed to have a three-year lifetime!

Computer

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 space shuttle

  1. Groups of sensors that are polled with fixed periodicities, not necessarily
  2. Sensor input triggers tasks which also run with the periodicity of the sensor

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. If the tasks won't fit in adjust the complete sensor/program system.

Make it easier yet

Prove some theorems, such as Liu & Layland. The essence of the theorems is

  1. The critical moment, which is guaranteed to exist, occurs when all three tasks are scheduled at once.
  2. If you choose task priorities so that the most frequently scheduled task has the highest priority, then,

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.

Small form-factor computing

In 1977, when Voyageou was launched, computation was expensive, so the action in computation was in big expensive things. Now computation is cheap, and the action is in small inexpensive things. Think about how a mobile telephone works.

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

This sounds easy. Why is it hard in practice?

Even more tricky, you have to handle foreign code, like apps.

Take advantage of real-time being defined in human terms.

All you need is code that handles over-runs in the cyclic exective without missing deadlines!


Return to: