CS452 - Real-Time Programming - Spring 2008

Lecture 33 - Scheduling Limits

Questions & Comments

1. Projects

Real-time Scheduling

Liquimedia

The Recital Model

• composer - no real-time link to audience necessary
• performer - real-time link to audience
• conductor - coordinates performers in real-time

Design Objectives

1. processor partitioning
   • between real-time and non-real-time
     • This forces programmers to think, which is good.
   • between performers
   • communication must be possible
2. synchronous execution
   • fast enough cycle to provide continuity to the user
   • predictable execution
   • common real-time clock determining cycle less that 10 milliseconds in length
3. modularity
   • understandable assignment of resources to tasks
   • foreign applications should be allowed
4. ultra-fine granularity
   • many performers do very little computation per cycle
   • overhead must be as close to zero as possible

Design features

1. Performers
   • atomic execution
   • relinquish processor voluntarily, like functions
2. Conductor
   • executes performers according to schedule prepared outside real-time by a composer
3. Admission control
4. Probabilistic estimation of performers running times
   • off-line test in composer
   • on-line test by conducter: enough time in the cycle according to estimate?
5. Procedures to handle failure
   1. hard limit to execution by watch-dog timer at cycle boundaries
   2. on-line test by conducter can postpone execution to next cycle
   3. scheduler updates schedule based on new
6. Asynchronous communication between tasks
   • based on conduits
   • non-blocking message passing

Return to:

• Bill Cowan's Winter 2008 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page