CS452 - Real-Time Programming - Spring 2011
Lecture 31 - Cyclic Execution
Pubilic Service Announcement
- Demos
- Last day of classes: Tuesday, 26 July
- First day of demos: Thursday, 28 July (11.00 - 14.00)
- Second day of demos: Friday, 29 July (11.00 - 14.00)
- Extra time available for second group: 21 hours = time second group
should be excluded.
- Therefore exclusion should run from 14.00, Wednesday, 27 July to
11.00, Thursday, 28 July.
- Exam
Cyclic Execution
Voyageur
33 years, 11 months, 0 days.
Computer
6000 word instruction and scratch data memory
62,500 Kbyte digitil tape recorder for storage of sensor data
System Software
Cyclic executive
Cyclic Execution
- Clock ticks
- Starts executing, in priority order, programs that are ready to
run.
- At end of programs, wait until the clock ticks, then go to 2.
- If clock ticks before end of programs, then report fault to earth and
go to 2.
- Cycle can be interrupts 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. Aren't you lucky!)
This is an abstract: with so little memory it is essential to squeeze out
every word.
Most of the programs have the form
- 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
- 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,
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
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
- 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, ... ) in length
- Schedule the master cycle by hand (= by brain)
- Standardize the processing at each point
- Minimize the interaction between tasks
- Simple procedure
- Processing needed by task i is pi
- Share of CPU needed by pi is si = pi/ni
- s1 + s2 + s3 + ... < 1. Otherwise you must,
- get a bigger processor, or
- reduce the amount of computing needed
- 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
- 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
Main idea
- Identify the bottleneck
- We call this the critical instant for a task.
Main result
- A method for deriving priorities from task characteristics
Subsidiary result
- Maximum possible CPU utilization
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.
- 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.
Your job
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 want asynchronous response from the phone
- It should slow down, not collapse, when you load it too
heavily.
- The easy way to do this is to hand the CPU over to a Unix-like OS
that operates in spare time at the end of each cycle.
- 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
- Apps are better if they can install tasks on the cyclic
executive
- Why? Apps like games have real-time demands.
But,
- Security is a problem because malicious apps can overrun
schedules, so you need admission control
- Performance is a problem because loading too many apps can
affect the quality of the telephone function, so you have to
involve the user in admission control.
Return to: