Real-Time Operating Systems

1. CSED191 | 컴퓨터공학소개 | November 2006 Real-Time Operating Systems 서광열, 류준호, 오병찬

2. What is a Real-Time OS? • A RTOS(Real-Time Operating System) • An Operating System with the necessary features to support a Real-Time System • What is a Real-Time System? • A system where correctness depends not only on the correctness of the logical result of the computation, but also on the result delivery time • A system that responds in a timely, predictable way to unpredictable external stimuli arrivals • 99% of all RTOS are for the embedded systems market

3. Examples of Real-Time Apps Audio • 1-10 ms Network Traffic Routing • Real-Time QOS(Quality of Service) contraints GSM cell phone • One TDMA frame/4.6 ms • Maximum latency guarnatee < 500 usec Video • HDTV 60 frames/sec -> 16 ms/frame

4. Type of Real-Time Systems • Hard Real-Time • Missing a deadline has catastrophic results for the system • Firm Real-Time • Missing a deadline causes an unacceptable quality reduction • Soft Real-Time • Reduction in system quality is acceptable • Deadlines may be missed and can be recovered from

5. Characteristics of RTOS • Scheduling • Intertask communication and resource sharing • Interrupt handlers and the scheduler • Memory allocation From Wikipedia

6. Scheduling • Minimize the worst-case length of time spent in the scheduler's critical section • Pre-emptive priority scheduling – higher priority tasks may interrupt lower priority tasks Running Task 1 Prio 7 Dispatch Block Task 2 Prio 5 Timer run-out Blocked Ready Wakeup Task 3 Prio 10 Choose the highest priority task

7. Intertask communication and resource sharing • Sharing data and hardware resources among multiple tasks • Unsafe for two tasks to access the same specific data or hardware resource simultaneously • Common approaches • Temporarily masking/disabling interrupts • Binary Semaphores • Message passing • RTOS • Priority Inversion Problem • Priority Inheritnace Low Priority High Priority Thread 1 Thread 2 Waiting Lock Held By 1 Shared Resource

8. Interrupt handlers and the scheduler Interrupts • Keep interrupt handlers as short as possible • Procedures • Acknowledge or disable the interrupt • The interrupt handler queues work to be done at a lower priority level, often by unblocking a driver task Top Half (Interrupt disabled) Deferred Process Bottom Half (Low priority) Linux Interrupt Handling Example

9. Memory Allocation Requirements • Problems • Speed of allocation: Scanning a linked list of indeterminate length is not acceptable • Memory fragmentation • Possible solution • Use simple fixed-size block allocation Fragmented Memory

10. CASE STUDY VxWorks

11. CASE: VxWorksFeatures • Modularized kernel • Many libraries and subroutines • High-speed interrupt process • Separated Task/Interrupt stacks • Shorter interrupt latency than Linux • Cross-compiling target software to run on various target CPU architectures

12. CASE: VxWorksThe pros • Multi-thread model OS • An application merges with OS kernel • It can access common workplace (memory) freely • The size of OS is small, good for small systems (easy to make)

13. CASE: VxWorksThe cons • A simple bug can spoil whole system • Specialized to some vendors • Commercial software • High license cost, even running royalty exists • Plus, the market of linux-based OS is going bigger and bigger

14. CASE: VxWorksUsages • Mars Pathfinder Lander fault protection • continuously monitors hundreds of parts of the spacecraft for a wide range of problems

15. CASE: VxWorksUsages (Continued) • Boeing 787 common core system • the backbone of the airplane's computers, networks and interfacing electronics

16. CASE STUDY Windows CE

17. CASE: Windows CEFeatures • Preemptive kernel • Predictable synchronization mechanism • Predictable and bounded interrupt latency

18. CASE: Windows CEPreemptive Multitasking • Eight levels of thread priority • Real-time processing device drivers • Kernel threads and normal applications • Applications that always can be preempted • Does not age priorities • Does not mask interrupts

19. CASE: Windows CEPredictable synchronization mechanism • Correct interaction between threads • mutex, critical section, and event objects • "FIFO-by-priority" order • First come first served order • Different queue for each priority levels

20. CASE: Windows CEInterrupt latency • Amount of time that elapse • Arrives at the processor • Interrupt processing begins • Bounded and predictable • Possible to calculate worst-case latency • Does not support nested interrupts

21. CASE STUDY Real-time Linux

22. CASE: Real-time LinuxLinux is not a Real-Time OS OOPS! Linux Linux Process Linux Process Linux Process Hardware (CPU, Memory, Disks, etc)

23. CASE: Real-time Linux(1) FSMLab’s RTLinux Linux Linux Process Linux Process RTOS FixedPriority Scheduler Lowest Priority RT Thread RT Thread RT Thread (Linux) Hardware (CPU, Memory, Disks, etc)

24. CASE: Real-time Linux(1) RTLinux Characteristics • RTLinux is nonpreemptible • Small size and limited operations guarantee predictable delay • Real-time tasks • Direct access to hardware • No virtual memory • Written as a special Linux module, dynamically loaded into memory • No Linux kernel modification

25. CASE: Real-time Linux(2) MontaVista’s Preemptive Kernel • 2.4 Linux kernel is not preemptive • Higher priority task should be suspended

26. CASE: Real-time Linux(2) Preemptive Kernel • Preemptive kernel • Originate from SMP supports (spinlocks) • Improve latency • Lock breaking • Some spinlocks contains a long loop • Voluntary Preemption • Use might_sleep() debugging macro • Release all held spinlocks and reacquire when awakened • Priority Inheritance Mutexes • The PI mutex patch replaces the spinlocks with priority inheritance mutexes • Others emhancements • BKL • Interrupt Threads • Read/write locks • Kernel lists/queues/fifos • Deadlock detection • Instrumentation

27. The End