1 / 53

Real-Time Operating Systems

Real-Time Operating Systems. Raquel S. Whittlesey-Harris. Contents. What is a real-time OS? OS Structures OS Basics RTOS Basics Basic Facilities Interrupts Memory Development Methodologies Summary References. What is a Real-time OS?. A RTOS (Real-Time Operating System)

Download Presentation

Real-Time Operating Systems

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

More Related