1 / 31

Real-time concepts

Real-time concepts. Lin Zhong ELEC424, Fall 2010. 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. Non real-time. Soft real-time. Hard real-time.

galatea
Download Presentation

Real-time concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Non real-time Soft real-time Hard 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 • ………

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

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

  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

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

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

  9. 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 ACM20 (1): 46–61

  10. Priority assignment Scheduling

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

  12. Feasibility analysis • 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

  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

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

  16. 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?

  17. 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 EnricoBini, 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

  19. 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 ?

  20. Synchronization Pre-empted C1 Task 1 T1 C2 Task 2 T2

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

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

  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();

  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

  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()

  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(); 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

  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

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

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

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

More Related