Real-time concepts
Lin Zhong
ELEC424, Fall 2010
Real time
Non real-time
Soft real-time
Hard real-time
• Correctness
– Logical correctness
– Timing
• Hard vs. Soft
– Hard: lateness is intolerable
• Pass/Fail courses
– Soft: lateness can be tolerated but penalized
• Regular courses
2
Example real-time systems
• Hard real-time systems
– Target acquisition system on jet fighters
– Electronic engine control unit
• Fuel injection
• Ignition timing
– Anti-lock braking system (ABS)
– Air traffic control
– Reservation system
• ………
3
Example real-time systems
• Soft real-time system
– Media player
– WiFi interface card
4
Model of a system
Key question
• Can the system finish the requests in time?
(Feasibility analysis)
Arrival of requests
Execution of tasks
5
Key variables
• Execution of requests
– Predictability
• Probabilistic distribution of execution time
– Range: Worst case execution time
• Arrival of requests
– Predictability
• Probabilistic distribution of arrival intervals
– Range: worst case
6
Tasks: unit of scheduling
• OS-based real-time system
– Process, threads
• OS-less real-time system
– Interrupt handlers
• Periodic vs. Aperiodic
7
Model of a system
Task 2
Task 1
• Feasibility analysis
Execution of tasks
8
Assumptions
• There are multiple tasks
– ti, i=1,…,m
• Tasks are periodic
– Ti
– Each occurrence is called a request
• Execution time for each task is known
– Ci
• Pre-emptive
• Tasks are prioritized
• Task switching is instant
Liu, C. L.; Layland, J. (1973), "Scheduling algorithms for multiprogramming in a hard real-time
environment", Journal of the ACM 20 (1): 46–61
9
Scheduling
Priority assignment
10
Definition of feasibility
Pre-empted
C1
Task 1
T1
C2
Task 2
T2
Every request of every task is finished before the next request of the task
11
Feasibility analysis
Given a set of tasks, how do we know if a feasible
scheduling exists?
• Sufficient condition
• Necessary condition
12
Fixed priority scheduling
• Each task has a fixed priority
• Rate monotonic scheduling (RMS)
– Higher request rate (1/T)  Higher priority
13
Theorem of RMS optimality
• A scheduling of a set of tasks is feasible if
deadlines of all requests are met
• Given a set of tasks, If a feasible scheduling
exists, the rate-monotonic scheduling is
feasible
• RMS is the best in terms of feasibility
– Give high priority tasks to high-rate tasks
14
Feasibility analysis
Given a set of tasks, how do we know if a feasible
scheduling exists?
• Sufficient condition
• Necessary condition
Given a set of tasks, how do we know if the RMS is
feasible?
15
Necessary condition
• Utilization of a system=(busy time)/(total time)
• Utilization factor for a set of tasks
– UF =Σ(Ci/Ti)
• Necessary condition of feasibility
– UF≤1
Can we make the bound for necessary
condition smaller?
16
Sufficient condition
• Theorem: if UF ≤ m(21/m-1), the set of tasks are feasible
– m(21/m-1)ln(2)≈0.69
• The bound is TIGHT
– There exists infeasible sets whose UF m(21/m-1)
• The opposite is NOT true
– Average real utilization factors of feasible sets is about 88%
• Theorem: if ∏(Ci/Ti+1) ≤2, the set of tasks are feasible
– Less pessimistic
Enrico Bini, Giorgio C. Buttazzo, Giuseppe M. Buttazzo, "Rate Monotonic Analysis: The Hyperbolic
Bound," IEEE Transactions on Computers, vol. 52, no. 7, pp. 933-942, July, 2003.
17
Dynamic priority scheduling
• Earliest deadline first (EDF)
– Higher priority to requests with earlier deadline
• The sufficient and necessary condition of
feasibility
– UF≤1
18
Assumptions
• There are multiple tasks
– ti, i=1,…,m
• Tasks are periodic
– Ti
– Each occurrence is called a request
?
• Execution time for each task is known
– Ci
• Pre-emptive
• Tasks are prioritized
• Task switching is instant
19
Synchronization
Pre-empted
C1
Task 1
T1
C2
Task 2
T2
20
Synchronization
• Task 1
– A[0] accelerometer
– B[0] A[0]
• Task 2
– If(A[0]!=B[0) exit
LD R13, (A[0]);
LD R14, (B[0]) ;
CMP R13, R14;
JEQ EXIT
21
Synchronization (Contd.)
• Critical section
– Section of code that access a shared resource that must
not be concurrently accessed by more than one thread of
execution
• Atomic operation
– A set of operations that appears to be one to the system
• System state change due to the operations invisible until all the
operations are successful
• If any of the operations fails, the entire set fails; and no change to the
system state
– Assembly instruction
– Disable interrupt
22
Lock-based synchronization
• Lock
– Limited access to critical section
• Task 1
– Lock(); A[0] accelerometer;
– B[0] A[0];
– Unlock();
• Task 2
– Lock(); If(A[0]!=B[0) exit; unlock();
23
Lock implementation
• Lock() and unlock() must be atomic
– A bit
– Lock()
•
•
•
•
Disable interrupt
check if the bit is set
if not, set it and enable interrupt;
else enable interrupt and wait;
– Unlock()
• Disable interrupt
• unset the bit;
• Enable interrupt
24
Lock implementation (Contd.)
• Lock()
–
–
–
–
Disable interrupt
check if the bit is set
if not, set it and enable interrupt;
else enable interrupt and wait;
• Spinning
– Keep on calling lock()
• Block
– Sleep
– The OS checks the bit and wake the blocked thread up
to call lock()
25
Lock implementation (Contd.)
• Task 1
– Lock(); A[0] accelerometer;
– B[0] A[0];
– Unlock();
• Task 2
– Lock(); If(A[0]!=B[0) exit; unlock();
Why don’t we simply replace lock() with disable_interrupt and
unlock() with enable_interrupt?
26
Programming primitives
• Semaphore
– A data structure for lock
– Allow multiple access to the data structure
• Mutex
– Binary semaphore
• Usually blocking
27
Problems with locks
• Priority inversion
– A low-priority task has the lock but has been preempted by a high-priority one
• Deadlock
– Two tasks each are holding a lock that is needed
by the other
• Convoying
– Multiple threads with equal priority contend for
the same lockToo many context switches
28
Transaction memory
• Transaction
WWW
– A series of speculated operations
– Commit or abort
• Implementation
– Hardware
– Software
WWW
Herlihy, M. and Moss, J. E. 1993. Transactional memory: architectural support for lock-free data
structures. SIGARCH Comput. Archit. News 21, 2 (May. 1993), 289-300
29
OS-less real-time system
• Latency in interrupt handling
– Predictable
• Arrival of interrupts
– Predictable (Periodic)
– Unpredictable (Aperiodic)
System idle
Interrupt Interrupt
• Any statistics?
• Worst case?
TimerA()
USARTRX()
Interrupt handlers
30
Real-time operating system (RTOS)
• Interrupt latency
WWW
– Interrupt controller
– Interrupt masking
– OS interrupt handling
• Thread switching latency
31