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
   • 25 August
     • Groups demoing on the 27th leave the lab at 13.00
   • 26 August
     • Code freeze at 9.00
     • Demos start at 9.30
       • 30 minutes in length
     • Demos end at 14.00, groups demoing on the 27th re-enter the lab
   • 27 August
     • Code freeze at 9.00
     • Demos start at 9.30
       • 30 minutes in length
     • Demos end at 14.00

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.
   • Checking for input from earth is one of the programs that is run.
   • Boot mode often entails loading a new program from earth. (At present loading takes many hours, and hours is getting close to days. Aren't you lucky!)

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

• the rotational speed of the wheels, and
• the exhaust mixture, and
• the torque, and
• the state of the controls, and ...

and a set of tasks that

• updates the engine parameters, such as combustion mixture, and
• updates the transmission parameters, such as shift speeds, and
• passes information to the instrument controller,
• and ...

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,

• but you can do better.

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.

• The total amount of thinking you have to do is finite.
• The thinking you do is inserting into the schedule the amount of processing that needs to be done
  • worst case
• Work it all out so that nothing collides.
  • using heuristics, no doubt

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.
   • Underlying clock.
   • sensor i is read once every ni ticks.
   • Master cycle is LCM( n1, n2, n3, ... ) in length
   • Schedule the master cycle by hand (= by brain)
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,
   • if there exists a schedule that meets all deadlines, then
   • your choice of task priorities meets all deadlines

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.

• If your project is CPU limited, it's the point where the maximum computation must be done before the CPU can get back to do the most important new thing.
• If you project is train communication bandwidth limited, then it's the point at which all curent users of bandwidth want to communicate at once.

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.

• It has housekeeping functions that must be done regularly, things like
  • telling the nearest ground station that it's ready to receive a call
  • updating the clock
  • refreshing the memory
• When you are making a phone call, there are phone call functions that must be done regularly
  • collecting packets of audio from the antenna
  • doing signal conditioning on the digital audio they contain.
  • putting the digital audio into data buffers from which they will be send to the speaker.
  • analogous things that intervene between the microphone and the antenna.

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

• It should slow down, not collapse, when you load it too heavily.
• The easy way to do this.
  • Put all of the regular functions into a cyclic executive, carefully analysing the run-time of each to make certain that everything will always get done on time.
  • In almost every cycle there is some time left over. In this time run an asynchronous OS that supports non-critical but still real-time features such as
    • managing the UI
    • texting
    • game playing
    • internet browsing
    • whatever else you can find at the app store.

    This is the kind of thing that your kernel can do well.

  • The definition of `non-critical' depends on the capabilities of the user. For example,
    • if a UI slows a little the user easily slows his or her reactions to accomodate
    • but if the sound drops out for a second in the middle of a word the user cannot pause his hearing in order to put the two halves of the word together

This sounds easy. Why is it hard in practice?

• It's necessary to share resources.
  • hardware, such as memory and I/O
  • software, such as data structures

  and battery life-time is what sells mobile phones

  • so resources are limited
• In particular, from the asynchro9nous UI the user starts functions, like phone calls, that are synchronous.
  • Synchronous/asynchronous communication is hard to accomplish while meeting tight real-time constraints.
  • Code must cross a synchronous/asynchronous boundary

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

• Deciding whether it's safe to include a new activity in the schedule, which is called admission control, requires knowing its performance characteristics.
• You can comfortably put your own code into the schedule because you trust the performace characteristics you received with it.
• Foreign code, which means code produced elsewhere, is not trustworthy.
• How can you include it in the schedule?

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

• If its reported performance characteristics are good enough install it.
• If it violates its performance characteristics during the first 100 milliseconds, then
  • it's probably incompetent. Reject it and tell the user why.
  • This looks real-time to the user.
• If it violates its performance characteristics later,
  • it could be malicious

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

Return to:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page