CS452 - Real-Time Programming - Spring 2010

Lecture 30 - Cyclic Execution

Public Service Announcements

Due date for Tracking 2
- Friday November 26, seven days from today.
- Bring your documentation to class.
Project plan

Real-time Scheduling

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

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

Typical example, a group of sensors that returns

the rotational speed of the wheels, and
the exhaust mixture, and
the torque, and ...

and a set of tasks that

updates the engine parameters, and
updates the transmission parameters, and
passes the speed on to the instrument controller, and ...

Each time a sensor returns a new datum a scheduler runs

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

Your kernel can handle problems like this one pretty efficiently,

but you can do better.

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.

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

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, ... )
- Schedule the master cycle by hand (= by brain)
Standardize the processing at each point
Minimize the interaction between tasks
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.
Prove some theorems, such as Liu & Layland

Theorems

Important assumptions

No interaction execpt contention for CPU
- system has a state
- all actions are predicated on the state as it is.
- otherwise, every task is self-contained.
All tasks scheduled periodically
Task must finish processing event n before event n+1 occurs
When tasks are ready simultaneously the higher priority one runs

Questions

How should priorities be chosen to produce satisfy all deadlines?
How much of the CPU is used when the choice above is optimal?

Main idea

Identify the bottleneck
It occurs when all tasks are ready to run at the same time.

Proof strategy

Definitions

Call the bottleneck the critical instant
Any schedule that satisfies all deadlines is called feasible.

Method

Assume that there exists a feasible schedule
Find transformations of the form
- If schedule A is feasible, then schedule B must be feasible.
Provide a sequence of transformations that starts with any feasible schedule and ends at the goal.
Show that the transformation applied to the goal gives only the goal.

Main result

A method for deriving priorities from task characteristics
- rate-monotone scheduling

Subsidiary result

Maximum possible CPU utilization is about 2/3

Is this of any practical value?

This is left as an exercise for the reader.

Return to: