1. Real-time concepts Lin Zhong ELEC424, Fall 2010

2. 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 Non real-timeSoft real-timeHard real-time

3. 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

4. Example real-time systems Soft real-time system – Media player – WiFi interface card 4

5. Model of a system 5 Execution of tasks Arrival of requests Key question Can the system finish the requests in time? (Feasibility analysis)

6. 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

7. Tasks: unit of scheduling OS-based real-time system – Process, threads OS-less real-time system – Interrupt handlers Periodic vs. Aperiodic 7

8. Model of a system 8 Execution of tasks Task 2 Task 1 Feasibility analysis

9. Assumptions There are multiple tasks – t i, i=1,…,m Tasks are periodic – T i – Each occurrence is called a request Execution time for each task is known – C i Pre-emptive Tasks are prioritized Task switching is instant 9 Liu, C. L.; Layland, J. (1973), "Scheduling algorithms for multiprogramming in a hard real-time environment", Journal of the ACM 20 (1): 46–61

10. 10 Scheduling Priority assignment

11. Definition of feasibility 11 C1C1 Pre-empted T1T1 T2T2 C2C2 Task 1 Task 2 Every request of every task is finished before the next request of the task

12. Feasibility analysis 12 Given a set of tasks, how do we know if a feasible scheduling exists? Sufficient condition Necessary condition

13. Fixed priority scheduling Each task has a fixed priority Rate monotonic scheduling (RMS) – Higher request rate (1/T)  Higher priority 13

14. 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

15. Feasibility analysis 15 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?

16. Necessary condition Utilization of a system=(busy time)/(total time) Utilization factor for a set of tasks – UF =Σ(C i /T i ) Necessary condition of feasibility – UF≤1 16 Can we make the bound for necessary condition smaller?

17. Sufficient condition Theorem: if UF ≤ m(2 1/m -1), the set of tasks are feasible – m(2 1/m -1)  ln(2)≈0.69 The bound is TIGHT – There exists infeasible sets whose UF  m(2 1/m -1) The opposite is NOT true – Average real utilization factors of feasible sets is about 88% Theorem: if ∏(C i /T i +1) ≤2, the set of tasks are feasible – Less pessimistic 17 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.

18. Dynamic priority scheduling Earliest deadline first (EDF) – Higher priority to requests with earlier deadline The sufficient and necessary condition of feasibility – UF≤1 18

19. Assumptions There are multiple tasks – t i, i=1,…,m Tasks are periodic – T i – Each occurrence is called a request Execution time for each task is known – C i Pre-emptive Tasks are prioritized Task switching is instant 19 ?

20. Synchronization 20 C1C1 Pre-empted T1T1 T2T2 C2C2 Task 1 Task 2

21. Synchronization Task 1 – A[0]  accelerometer – B[0]  A[0] Task 2 – If(A[0]!=B[0) exit 21 LD R13, (A[0]); LD R14, (B[0]) ; CMP R13, R14; JEQ EXIT

22. Synchronization (Contd.) 22 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

23. 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

24. 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

25. 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

26. Lock implementation (Contd.) Task 1 – Lock(); A[0]  accelerometer; – B[0]  A[0]; – Unlock(); Task 2 – Lock(); If(A[0]!=B[0) exit; unlock(); 26 Why don’t we simply replace lock() with disable_interrupt and unlock() with enable_interrupt?

27. Programming primitives Semaphore – A data structure for lock – Allow multiple access to the data structure Mutex – Binary semaphore Usually blocking 27

28. Problems with locks Priority inversion – A low-priority task has the lock but has been pre- empted 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

29. Transaction memory Transaction – A series of speculated operations – Commit or abort Implementation – Hardware – Software 29 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 WWW

30. OS-less real-time system Latency in interrupt handling – Predictable Arrival of interrupts – Predictable (Periodic) – Unpredictable (Aperiodic) Any statistics? Worst case? 30 TimerA() USARTRX() Interrupt handlers System idle Interrupt

31. Real-time operating system (RTOS) Interrupt latency – Interrupt controller – Interrupt masking – OS interrupt handling Thread switching latency 31 WWW