CS 452/652 Winter 2024 - Lecture 21

Real-time Scheduling

Mar 26, 2024 prev next

embedded (special-purpose) system
- hardware / operating system / application co-design
- guaranteed response latency - predictability! (too early?)
- run-to-completion
- hard vs. firm vs. near vs. soft real-time (no strict terminology)
  - hard: "no delay"
  - firm: rate delay miss ok
  - near: some delay ok
  - soft: statistical distribution of response times ok, degrading utility
general-purpose computer system
- hardware - operating system - application: independent designs
- throughput and fairness objectives
- pipelining
- hard real-time almost impossible

polling loop w/ strict timing
components: subroutine or coroutine
- subroutine runs to completion
- coroutine suspends/resumes (typically on stack)
known upper bound for each component
sleep to fill gaps → predictable timing

        t = current_time();
        if (C1) then A1;
        ...
        sleep(t + target - current_time());

separate OS kernel and application tasks for flexibility
- dynamic creation of tasks
- tasks annotated with real-time requirements
periodic (arrival, run-time) vs. aperiodic tasks (sporadic)
- aperiodic much more difficult to analyze
admission control: set of feasible real-time tasks
selection mechanism (actual scheduling)
- static vs. dynamic priority
- hybrid: can have background tasks
mathematical model to related selection mechanism to admission control

Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment
periodic tasks, strict priority, immediate preemption
describe task $\tau_i$ with period $T_i$ and work $C_i$ , utilization $U_i = C_i/T_i$
example

$tau$ T C U

1 10 2 0.2

2 5 2 0.4

3 3 1 1/3
question: is set of tasks & priorities feasible?
simulate "critical instant": largest response time - task request simultaneously with all higher priority tasks - -esponse time: completion time - arrival time

$tau$	T	C	U
1	10	2	0.2
2	5	2	0.4
3	3	1	1/3

simulate execution up to first deadline of lowest priority task

confirm that all requests (jobs) meet their deadlines: necessary and sufficient
- necessary because eventually all tasks will arrive at the same time
- sufficient because this checks the worst-case response time of all tasks

$\tau$	T	C	U	1	2	3	4	5	6	7	8	9	10	Priority
1	10	2	0.2	1	1
2	5	2	0.4	2	2				2	2
3	3	1	1/3	3			3			3			3
				3	2	2	3	1	2	3	2	1	3	3 > 2 > 1
				2	2	3	3	1	2	2	3	1	3	2 > 3 > 1
				1	1	2	X							1 > 2 > 3

how to assign priorities?
rate-monotonic (RM) scheduling
- assign priorities according to arrival rate (not utilization!)
- if $\sum_{i=1}^{n} U_i < n * (2^{n-1}-1)$ , RM schedule guarantees deadlines
- bound approaches $ln(2)\approx 0.693$ (from the top)
- no simulation needed
- this is a sufficient test, not a necessary one
  - task sets with higher utilizations might be schedulable
  - example task set has higher utilization, but is still schedulable
- optimal scheduling scheme for static priorities
harmonic task set: each tasks period's is exact multiple of next most frequent task
→ 100% utilization possible with RM scheduling
dynamic priorities: earliest deadline first (EDF) scheduling → 100% utilization possible
- optimal scheduling algorithm
- but $O(logN)$ computional overhead each time
$\tau$ T C U 1 2 3 4 5 6 7 8 9 Schedule

1 8 1 0.125 1 1

2 5 3 0.6 2 2 2 2 2 2

3 4 1 0.25 3 3 3

3 2 2 2 3 2 2 2 X RM

3 2 2 2 3 1 2 2 2 EDF (*)
- (*) $\tau_1$ and $\tau_3$ in any oder in Interval 5 & 6
overload behaviour
- rate-monotonic: starvation
- EDF: no guarantees

$\tau$	T	C	U	1	2	3	4	5	6	7	8	9	Schedule
1	8	1	0.125	1								1
2	5	3	0.6	2	2	2			2	2	2
3	4	1	0.25	3				3				3
				3	2	2	2	3	2	2	2	X	RM
				3	2	2	2	3	1	2	2	2	EDF (*)

rate-monotonic scheduling seems sufficient
- scheduling analysis vs. latency analysis
scheduling:
- service tasks, identical engineers - arrival, runtime?
- interrupt handling latency minimal
- assess how many trains can be controlled
- CPU not bottleneck - track limits number of trains running!
train control latency:
- central event query and sensor attribution
- central train/track operations - buffering?