CS 452/652 Spring 2025 - Lecture 14

Real-time Scheduling

Jun 19, 2025 prev next

special-purpose) computer system (often embedded)
- hardware / operating system / application co-design
- guaranteed response latency - predictability! (too early?)
- concurrency: run-to-completion
- hard vs. firm vs. near vs. soft real-time (no strict terminology)
  - hard: "no delay"
  - firm: rare 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
- concurrency: pipelining, batching, buffering
- 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?

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

simulate "critical instant": largest response time

task request simultaneously with all higher priority tasks
response time: completion time - arrival time
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		Priority	1	2	3	4	5	6	7	8	9	10
1	10	2	0.2	Arrival		1	1
2	5	2	0.4			2	2				2	2
3	3	1	1/3			3			3			3			3
				Service	3 > 2 > 1 (frequency)	3	2	2	3	1	2	3	2	1	3
					2 > 3 > 1 (utilization)	2	2	3	3	1	2	2	3	1	3
					1 > 2 > 3 (period)	1	1	2	X

how to assign priorities?
rate-monotonic (RM) scheduling
- assign priorities according to arrival rate (frequency, not utilization!)
- if $\sum_{i=1}^{n} U_i < n * (2^{1/n}-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
  - some task sets with higher utilizations might be schedulable
  - example task set has higher utilization, but is still schedulable
- RM is 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

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

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?