Real-time Operating Systems – An Introduction

1. Real-time Operating Systems – An Introduction Swaminathan Sivasubramanian and Sai Sudhir A swami@cs.vu.nl saisud@iastate.edu

2. outline Outline • Capabilities of RTOS • Some Services in detail • Types of RTOS • Case studies

3. What is an RTOS • Provides efficient mechanisms and services for real-time scheduling and resource management • Must keep its own time and resource consumption predictable and accountable • Used in the following areas such as: • Embedded Systems or Industrial Control Systems • Parallel and Distributed Systems • E.g. LynxOS, VxWorks, pSoS, Spring, ARTS, Maruti, MARS

4. Capabilities • Conformance to Standards (Real-Time POSIX) • POSIX- Portable Operating Systems Interface, an API standard • Defines Real-time and thread extensions for RTOS • Prioritized scheduling, signals, high-resolution timer, IPC primitives • Creation and management of threads

5. Capabilities (contd..) • Modularity and Scalability • Footprint of the kernel – how huge is the kernel? • Can the kernel be scaled down to fit in the ROM of the system for small embedded applications • I/O, File and Networking services provided by additional components

6. RTOS – Capabilities (contd..) • Type of RTOS kernel • Monolithic kernel – tightly integrated services, less run-time overhead but not extensible • Microkernel – high run-time overhead but highly extensible

7. RTOS – Capabilities (contd..) • Speed and Efficiency • Run-time overhead – most of the modern RTOSes are microkernels (more overhead), but unlike traditional microkernels they’ve less overhead • Run-time overhead is decreased by reducing the unnecessary context switch • Important timings such as context switch time, interrupt latency, semaphore get/release latency must be minimum

8. Capabilities (contd..) • System Calls • Non preemptable portions of kernel functions necessary for mutual exclusion are highly optimized and made short and deterministic • Interrupt Handling • Non preemptable portions of the interrupt handler routines are kept small and deterministic • Interrupt handlers are scheduled and executed at appropriate priority

9. RTOS – Capabilities (contd..) • Scheduling • Type of scheduling supported – RMS or EDF • Number of priority levels supported – 32 to be RT-POSIX compliant; many offer between 128-256 • Type of scheduling for equal priority threads – FIFO or Round-Robin • Thread priorities be changed at run-time

10. RTOS – Capabilities (contd..) • Priority Inversion Control • Does it support Priority Inheritance or Ceiling protocols for scheduling? • You can disable it to save the overhead of these mechanisms • Clock and Timer Resolution • Provides fine timer resolution

11. Capabilities (contd..) • Memory Management • Can provide virtual-to-physical address mapping • Traditionally does not do paging • Can offer Memory Protection • Networking • Type of networking supported – deterministic network stack or not, support for TCP/IP

12. Some Services • Timer Services • System has at least one clock device consisting of a counter, a timer queue and an interrupt handler • Content of counter gives current time, timer queue has pending timers associated with the clock device • S/W clock associated with clock device, the latter raises interrupts periodically and kernel updates S/W clock according to current time

13. Timer Services (contd..) • Resolution of S/W clock equal to period of these interrupts (typically in milliseconds- not enough for most RT applns.) • Finer the resolution, larger the amount of time kernel spends in responding to interrupts thus limiting the resolution • Some implementations allow user threads to read the H/W clock directly for finer resolution by mapping H/W clock on to address space of application e.g. Pentium time stamp counter

14. Some Services (contd..) • Scheduling (Fixed priority) • 256 priority levels • Assigned priority- When the thread is created according to scheduling algorithm • Current priority- Thread can inherit higher priority • Ready queue for each priority level, thread placed in queue corresponding to its current priority

15. Scheduling (contd..) • Within each queue round-robin or FIFO scheduling • Thread should change its own priority to support Dynamic priority scheduling, very expensive if this capability is provided through a system call • So its better for the kernel to provide its own dynamic priority scheduling data structures

16. Some Services (contd..) • Memory Management • Virtual Memory Mapping - Embedded RT systems may not support this, system directly creates physically contiguous blocks of memory, but fragmentation can occur • Memory Locking – Paging introduces unpredictability, RTOS can support paging so that memory demanding applns (editors, debuggers) can co-exist

17. Memory management (contd..) • Memory Protection – Many RTOS don’t provide protected address space for simplicity and light weight of system calls • To control paging, application can pin its pages in memory so that they aren’t swapped out • But change in one module might require retesting the entire system, so RTOS provides the application the choices in memory management

18. TYPES of RTOS • Commercial RTOS • e.g., VxWorks (Wind River Systems), LynxOS (Lynux Works) • Real-time flavor to commercial OS • e.g., RT-Linux, KURT (Univ Kansas) • Research kernels • e.g., HARTS (UMich), Spring (UMass)

19. Lynx OS • Microkernel design • Means the kernel footprint is small • Only 28 kilobytes in size • The small kernel provides essential services in scheduling, interrupt dispatching and synchronization • The other services are provided by kernel lightweight service modules, called Kernel Plug-Ins (KPIs)

20. Lynx Os (contd..) • New KPIs can be added to the microkernel and can be configured to support I/O, file systems, TCP/IP, streams and sockets • Here KPIs are multi-threaded, which means each KPI can create as many thread as it wants

21. Lynx OS (contd..) • There is no context switch when sending a message to a KPI • For example, when a RFS (Request for Service) message is sent to a File System KPI, this does not request a context switch • Hence run-time overhead is minimum • Further, inter KPI communication incurs minimal overhead with it consuming only very few instructions

22. Lynx OS (contd..) • Lynx OS is a self hosted system – wherein development can be done in the same system • In such a system, there is a need for protecting the OS from such huge memory consuming applications (compilers, debuggers) • LynxOS offers memory protection through hardware MMUs

23. Lynx OS (contd..) • Applications make I/O requests to I/O system through system calls • Kernel directs I/O request to the device driver • Each device driver has an interrupt handler and kernel thread

24. Lynx OS (contd..) • The interrupt handler carries the first step of interrupt handling • If it does not complete the processing, it sets an asynchronous trap to the kernel • Later, when kernel can respond to the software interrupt, it schedules an instance of the kernel thread to complete the interrupt processing – Priority Tracking

25. VxWorks • Monolithic Kernel • Leads to an improved performance with less run-time overhead • However the scalability is poor I.e. the footprint of the kernel is affected a little. • Provides interfaces specified by RT-POSIX standards in addition to its own APIs • Though not a multiprocessor OS, provides shared-memory objects: shared binary and counting semaphores

26. VxWorks (contd..) • It has the standard MMU as a modern OS • Provides basic virtual-to-physical memory mapping • Allows to add new mappings and make portions of memory non cacheable • When memory boards are added dynamically, to increase the address space for interprocess communication • The data is made non cacheable, to ensure cache consistency

27. VxWorks (contd..) • Reduced Context Switch time • Saves only those register windows that are actually in use (on a Sparc) • When a task’s context is restored, only the relevant register window is restored • To increase response time, it saves the register windows in a register cache – useful for recurring tasks

28. ARTS - Distributed OS • Distributed real-time OS – provides a predictable distributed real-time computing environment

29. ARTS (Contd..) • Distributed computing environment • Heterogeneous computing environment • Need for global view of the system and resources • No over-utilization and under-utilization of a particular system in a distributed system • Guaranteeing predictability in such a system is difficult than in multiprocessor system case • How to synchronize the clocks in a distributed system?

30. ARTS (contd..) • Scheduling • Integrated time-driven scheduler • ITDS scheduler provides an interface between the scheduling policies and the rest of the operating system • Allows different scheduling policies to exist (though only one can be used at a time) • Communication scheduling • Extended RMS for communication scheduling – integrating message and processor scheduling