Real-Time Operating Systems

1. Real-Time Operating Systems Raquel S. Whittlesey-Harris

2. Contents • What is a real-time OS? • OS Structures • OS Basics • RTOS Basics • Basic Facilities • Interrupts • Memory • Development Methodologies • Summary • References

3. What is a Real-time OS? • A RTOS (Real-Time Operating System) • Is an Operating Systems 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

4. Real-Time OS • What a Real-Time System is NOT • A Transactional system • Average # of transactions per second • A Good RTOS is one that has a bounded (predictable) behavior under all system load scenarios • Just a building Block • Does not guarantee system correctness

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

6. Types of Real-Time Systems • Soft Real-Time • Reduction in system quality is acceptable • Deadlines may be missed and can be recovered from • Non Real-Time • No deadlines have to be met

7. OS Structures • Monolithic OS • OS is composed of one piece of code divided into different modules • Problem: Difficult to debug • Changes may impact other modules substantially • Corrections may cause other bugs to show up • “Spaghetti Software” - many interconnections between modules

8. OS Structures

9. OS Structures • Layered OS • Better approach than the Monolithic • However still chaotic • Example: OSI Layer • Problem: OS technology not as orthogonal with its layers • You can skip layers in OS model

10. OS Structures

11. OS Structures

12. OS Structures • Client-Server OS • Newer Model • Limit Basics of OS to a minimum (scheduler and synchronization primitive) • Other functionality is implemented as system threads or tasks • Applications are clients requesting services via system calls to these server tasks

13. OS Structures • Benefits • Easier to Debug and scale • Distribution over multiple processors is simpler • Possible to dynamically load and Unload modules • Problems • Overhead is high due to memory protection • Server processes must be protected • Increased time to switch from application’s to server’s memory space

14. OS Structures

15. OS Basics • An OS is a system program that provides an interface between application programs and the computer system (hardware) • Primary Functions • Provide a system that is convenient to use • Organize efficient and correct us of system resources

16. OS Basics • Four main tasks of OS • Process Management • Process creation • Process loading • Process execution control • Interaction of the process with signal events • Process monitoring • CPU allocation • Process termination

17. OS Basics • Interprocess Communication • Synchronization and coordination • Deadlock and Livelock detection • Process Protection • Data Exchange Mechanisms • Memory Management • Services for file creation, deletion, reposition and protection • Input/Output Management • Handles requests and release subroutines for a variety of peripherals and read, write and reposition programs

18. RTOS Basics

19. RTOS Basics • Central Purpose of a RTOS • Scheduling of the CPU • Applications are structured as a set of processes • Processes consist of • Code • State • Register values • Memory values

20. RTOS Basics • At least 3 states are needed to allow the CPU to schedule • Ready – waiting to run (in ready list) • Running – process (thread or task) is utilizing the processor to execute instructions • Blocked – waiting for resources (I/O, memory, critical section, etc.)

21. RTOS Basics

22. RTOS Basics • Threads are lightweight processes • Inherits only part of process • Belongs to the same environment as other threads making up the process • May be stopped, started and resumed • Tasks are a set of processes with data dependencies between them

23. RTOS Basics Max number of threads, tasks or processes • Definition space part of system • A system parameter • Definition space part of task • Available memory

24. Basic Facilities • Multitasking is required to develop a good Real-time application • “Pseudo parallelism” - to handle multiple external events occurring simultaneously • Rate Monotonic Scheduling (RMS) - is utilized to compute in advance the processor power required to handle the simultaneous events

25. Basic Facilities • Algorithms (scheduling mechanism) are needed to decide which task or thread will run at a given time • Function is to switch from one task, thread, or process to another (Context Switching) • Overhead – should be completed as quickly as possible • Dispatch time should be independent of the number of threads in the ready list • Ready list should be organized each time an element is added to the list

26. Basic Facilities

27. Basic Facilities

28. Basic Facilities • Types of Scheduling Policies • Deadline driven – ideal but not available • Cooperative – relies on current process to give up the CPU • Pre-emptive priority scheduling – higher priority tasks may interrupt lower priority tasks • Static – priorities are set before the system begins execution • Dynamic – priorities can be redefined at run time

29. Basic Facilities • Many priorities levels in a RTOS is better to have for complex systems with many threads • At least 128 levels • A different priority level can be set for each task or thread • Round Robin – give each task an equal share of the processor • Implemented when all tasks or threads have the same priority level • May be implemented within a priority range

30. Basic Facilities • Synchronization and exclusion objects • Required so that threads and tasks can execute critical code and to guarantee access in a particular order • Semaphores – synchronization and exclusion • Mutexes - exclusion • Conditional variables – exclusion based on a condition • Event flags – synchronization of multiple events • Signals – asynchronous event processing and exception handling

31. Basic Facilities • Communications • Data may be exchanged between threads and tasks via • Queues – mulitple messages • Mailboxes – single messages • Most RTOSs pass data by pointer • Copying data structure would be less efficient • Pointer must be valid while receiving thread or task makes use of it

32. Interrupts • RT systems respond to external events • External events are translated by the hardware and interrupts are introduced to the system • Interrupt Service Routines (ISRs) handle system interrupts • May be stand alone or part of a device driver • RTOSs should allow lower level ISRs to be preempted by higher lever ISRs • ISRs must be completed as quickly as possible

33. Interrupts • RTOSs vary in model of interrupt handling to task run

34. Interrupts • Interrupt Dispatch Time • time the hardware needs to bring the interrupt to the processor • Interrupt Routine • ISR execution time • Other Interrupt • Time needed for managing each simultaneous pending interrupt • Pre-emption • Time needed to execute critical code during which no pre-emption may happen

35. Interrupts • Scheduling • Time needed to make the decision on which thread to run • Context Switch • Time to switch from one context to another • Return from System Call • Extra time needed when the interrupt occurred while a system call was being executed

36. Interrupts • System calls cause software interrupts (SWIs) • Portable Operating System Interface (POSIX) defines the syntax of many of the library calls that execute the SWIs • Attempts to make applications portable

37. Memory • RAM • Holds changing parts of the task control block, stack, heap • Minimum number of RAM required varies by vendor • Maximum addressable space will vary depending on the memory model • E.g., backward compatibility (x86) will limit to 64K segments

38. Memory • Predictability • The need to make memory access “predictable” (bound) prohibits the use of virtual memory • Systems should have locking capability – prevent swapping by locking the process into main memory • Paging map should be part of the process context (loaded onto the processor or MMU) • Larger page sizes may be required to fit it all in 2k

39. Memory • Segments may be used to avoid 2k limit • Non-variable segment sizes may be used • Prohibit deallocation to prevent garbage collection (prevents displaced tasks from running which leads to unpredictability)

40. Memory • Static memory allocation • All memory allocated to each process at system startup • Expensive • Desirable solution for Hard-RT systems • Dynamic memory allocation • Memory requests are made at runtime • Should know what to do upon allocation failure • Some RTOSs support a timeout function

41. Development Methodology • RTOS differ in development configurations supported • Host – machine on which the application is developed • Target – machine on which the application is to execute

42. Development Methodology • Host = Target • Host and target are on the same machine • RTOS has its own development environment (compiler, debugger, and perhaps IDE) • Usually of lesser quality • Host  Target • Two different machines linked together (serial, LAN, bus, etc.) • Host generally machine with a proven General Purpose Operating System (GPOS)

43. Development Methodology • Better development environment • Debugger is on host while application is executed on target • Debug agents are stored on target to communicate with host • Simulator should be provided to execute prototype application on the host • Hybrid • Host and target on same machine but on different OSs • Communicate via shared memory

44. Development Methodology • Resource and hardware shared • May prevents RTOS from predictable behavior • May prevent GPOS from housekeeping duties • Multiprocessor environment should improve performance

45. Summary • A RTOS should be predictable regardless of the system load and size of queues/lists • RTOS should always support pre-emptive priority scheduling • The memory model utilized is very important to the performance and predictability of your RT system

46. Summary

47. Summary

48. Summary

49. Summary

50. Summary