Real Time Operating Systems

1. Real Time Operating Systems FatehaKhanamBappee ID: 201104674 Dept. of Mathematics, Statistics & Computer Science St. Francis Xavier University Antigonish, NS June 11, 2012

2. Presentation Outline • Introduction • Time Services and Scheduling Mechanisms • Other Basic Operating System Functions • Capabilities of Commercial Real-Time Operating Systems • Predictability of General Purpose Operating Systems

3. Introduction Criteria for a good RTOS: A good real-time operating system • provides efficient mechanisms and services for scheduling and resource management • keep its own time and resource consumption predictable

4. Introduction RTOS for embedded systems: Real-time operating systems for embedded systems have often a small real-time microkernel • because of memory limitations • in order to be able to simplify the certification of correctness, since many embedded RTOS will be used for safety-critical applications. Such a microkernel will only provide the basic essential services, such as scheduling, synchronization, and interrupt handling.

5. Introduction Tasks and Threads: A thread implements a computation job and is the basic unit of work handled by the scheduler. • When the kernel creates a thread, it allocates memory space to the thread • It also instantiates a data structure, the Thread Control Block (TCB).

6. Thread Control Block (TCB)The Thread Control Block keeps all information needed to manage and schedule the thread. Figure 1: Thread Control Block

7. Thread Control Block When a thread is • executing, its context is changed continuously. • stops execution, its context is stored in the thread‘s TCB. • 'put in a queue' (ready queue, suspend queue), a pointer to the threads TCB is put in the linked list representing the queue. • destroyed, the kernel deletes the TCB and deallocates its memory space.

8. Tasks and Threads Periodic Tasks • A periodic task is a thread that executes periodically. • Not all micro-kernels support periodic threads • In case periodic threads are not supported by the microkernel, periodic tasks need to be implemented at the user level.

9. Tasks and Threads Periodic Threads • After completion of a thread, the thread is reinitialized and put to sleep until the next period. • Microkernel keeps track of the time and releases it at beginning of next ready queue. • Typical parameters for a periodic thread in the TCB - phase - period - relative deadline - number of executions (may be finite)

10. Tasks and Threads Major states of a thread : The following thread states are often used by a microkernel. • Sleeping: A thread is in sleeping state after creation or completion. It will stay in this state until it is released. It is not eligible for execution. • Ready: A thread is in this state, when it released or preempted and is not blocked. It is eligible for execution. • Executing: A thread is in this state, if it is executing. • Suspended (Blocked): A thread is in this state if it is released but has not yet completed, since it cannot proceed to a lack of a resource or budget. • Terminated: A thread enters this state, if it will not execute again. Threads in this state may be destroyed.

11. Microkernel The microkernel takes under the following circumstances control from the executing thread and executes itself: • to respond to a system call • do scheduling and service timers • handle external interrupts

12. Structure of a Microkernel Figure 2: Structure of a microkernel

13. System Calls • A system call is a call to one of the RTOS API functions. • When the system call is executed, the kernel saves the context of the calling thread and switches from user mode to kernel mode. • The kernel executes then the system call and executes a return from exception, which means that the system returns to user mode. • Then the ready thread with the highest priority will be scheduled and starts to execute.

14. Memory Protection Many RTOS for embedded systems do not provide memory protection. The kernel and user execute in the same memory space. • Pros: - Much less memory is needed. Full memory protection requires a few kilobytes per process. - Memory protection increases context switch time. • Cons: - Data corruption even in the kernel space can occur.

15. Timer Services and Scheduling At each clock interrupt the kernel • processes timer events • updates execution budget • updates ready queue and returns control

16. Timer Services and Scheduling Processing of Timer Events: • All timer expiration times are stored in the timer queue. • Kernel checks, if timer events have occurred and takes the appropriate action. Update of Execution Budget: • If threads of equal priority are supported by the RTOS, they are often scheduled using time-slicing (Round-Robin). • Here the kernel has to monitor the 'execution budget' for each thread. • If the budget is exhausted, the thread is preempted. Update of Ready Queue: • Kernel updates the ready queue. • Kernel gives control to the thread in the ready queue with highest priority.

17. External interrupts • Interrupt is an efficient mechanism to handle external events, such as the notification of an IO event. • Handling interrupts is an essential function of the kernel. • The amount of time that is required to handle an interrupt varies and can be considerably long. • Service routines for disk and network devices can take hundreds of microseconds to tens of milliseconds to complete. • Interrupts need to be handled in a very short time frame in order to allow that all other tasks meet their deadline.

18. Hardware and thread interrupt priorities Figure 3: Hardware and software interrupt priorities

19. Interrupt handling In order to allow for an efficient interrupt handling, in many operating systems interrupt handling is often divided into two steps. • Immediate interrupt service - executed at interrupt priority level • Scheduled interrupt service - scheduled as a software priority level

20. Immediate interrupt service The total interrupt latency is calculated as the time • to complete instruction and jump to software interrupt handler of kernel • to disable external interrupts • to complete the immediate interrupt service routines of higher-priority interrupts, if any • to save context of interrupted thread, identify interrupted device, and get starting address of interrupt service routine • to start the immediate interrupt service routine of the interrupting device

21. Scheduled Interrupt Service • Immediate interrupt service does not complete interrupt handling. • Instead in order to shorten the time that user threads are delayed by the interrupt, the second step of the interrupt is done using a scheduled interrupt handling routine. • This routine is typically preemptable and scheduled as a thread on a software priority level. Scheduled interrupt service routines can be viewed as ape-riodic or sporadic threads.

22. Scheduling Mechanisms Fixed-Priority Scheduling • All modern operating systems support fixed-priority scheduling. • The assigned priority is kept in the TCB. • If protocols like priority inheritance protocol are used, even current priority has to be part of the TCB. • Kernel maintains a ready queue for each priority level. When a thread is ready to execute, it is put in the queue that corresponds to its current priority.

23. Scheduling Mechanisms Dynamic Priorities: • Most operating systems support even dynamic priorities. This means that there is a system call that a thread can use in order to change its own or another threads priority. • Mechanism is too expensive to support dynamic scheduling policies such as EDF.

24. Scheduling Mechanisms EDF Scheduling: • Kernel can provide direct support for EDF scheduling. • Same concept as for fixed-priority scheduling can be adapted for EDF - The system call for creating the thread includes the relative deadline - When a thread is released, the absolute deadline is calculated from its release time and the relative deadline. • The scheduler keeps a FIFO queue for the threads of each relative deadline. • Scheduler checks the head of each queue to find the thread with earliest absolute deadline.

25. Scheduling Mechanisms EDF Scheduling: Figure 4: Queue structure for EDF scheduling

26. RTOS Standards • There exist a number of standards for real-time operating systems. • At present the standards specify portability at the source code level, but the code needs to be recompiled for each operating system. • At present there are the following main operating system standards - RT-POSIX - general-purpose operating system with real-time extensions - OSEK - automotive industry - APEX - avionic systems - µITRON - embedded systems

27. Other Basic Operating System Functions • Communication and Synchronization • Software interrupt • Memory management • I/O and networking

28. Communication and Synchronization Other Basic Operating System Functions Message Queues: • a message queue provides a place where one or more threads can pass messages to some other thread or threads. • Real-Time POSIX message queue interface functions are mq_send( ) and mq_receive( ). • The service provider creates a message queue, gives the message queue a name, and makes this name known to its clients.

29. Communication and Synchronization Other Basic Operating System Functions Message Queues: • Prioritization - message queues should be priority queues -The sending thread can specify the priority of its message in its send message call -Real-Time POSIX message queues have priorities in the range [0, MQ_MAX_PRIO] • Message-Based Priority Inheritance - ensure consistent prioritization - A QNX server process (i.e., a service provider) receives messages in priority order -Real-Time POSIX does not support message-based priority inheritance • No Block and Notification - nonblocking - a message queue notifies a process when the queue changesfrom being empty to nonempty

30. Communication and Synchronization Other Basic Operating System Functions Synchronization Mechanisms: Threads (and processes) synchronize using mutexes, reader/writer locks, conditional variables, and semaphores. • Basic Primitives - the operating system provides two functions: inherit_pr( ) and restore_pr( ) - The function inherit_pr(TH) is called when a thread (named TH here) is denied a resource R and becomes blocked - The function restore_pr( ) is called when a resource is released. • Inheritance Function • Priority Restoration

31. Communication and Synchronization Other Basic Operating System Functions Figure 5: Priority inheritance primitives

32. Communication and Synchronization Other Basic Operating System Functions Figure 6: Blocking chain

33. Event Notification and Software Interrupt Other Basic Operating System Functions • Event notification, exception handling, and software interrupts are essential for multitasking systems. • Signal is the general mechanism to inform threads of the occurrences of timer events, the receipt of messages, the completion of asynchronous I/O operations

34. Event Notification and Software Interrupt Other Basic Operating System Functions • Signal and Similar Mechanisms - in a UNIX system, interrupt handlers and the kernel use signals to inform threads of the occurrences of exceptions - A thread may signal another thread to synchronize and communicate. - in Windows NT, events and Asynchronous Procedure Calls (APCs) serve the same purposes as signals in UNIX systems. - the POSIX subsystem uses APCs as software interrupts - the pSOSystem provides events and asynchronous signals

35. Event Notification and Software Interrupt Other Basic Operating System Functions • Real-Time POSIX Signals POSIX real-time extensions change the POSIX signals to make the mechanism more responsive and reliable. Distinction of signals conforming to POSIX real-time extensions from POSIX and traditional UNIX signals: First, real-time signals can be queued, while traditional UNIX signals cannot. Second, a queued real-time signal can carry data. A traditional signal handler has only one parameter: the number of the signal. Third, queued signals are prioritized: The smaller the signal number, the higher the priority. They are delivered in priority order. Fourth, POSIX real-time extensions provide a new and more responsive synchronous signal-wait function called sigwaitinfo.

36. Memory Management Other Basic Operating System Functions A task is not admitted into the system if there is not enough memory to meet its peak memory space demand. The main features of memory management are: - Virtual Memory Mapping. - Paging - Memory Protection. Some real-time applications do not need these capabilities, and do not get these capabilities without penalty.

37. Memory Management Other Basic Operating System Functions Virtual Memory Mapping: • Real-time operating systems designed for embedded real-time applications such as data acquisition, signal processing, and monitoring may not support virtual memory mapping. Example: pSOSystem. • Memory fragmentation is a potential problem for a system that does not support virtual mapping. • The solution is to provide virtual memory mapping from physical addresses, which may not be contiguous, to a contiguous, linear virtual address space seen by the application. • The penalty of virtual address mapping is the address translation table, which must be maintained and hence contribute to the size of the operating system.

38. Memory Management Other Basic Operating System Functions Memory Locking: • A real-time operating system may support paging • Real-Time POSIX-compliant systems allow an application to pin down in memory all of its pages or a range of pages • The LynxOS operating system controls paging according to the demand-paging priority. Memory pages of applications whose priorities are equal to or higher than this priority are pinned down in memory while memory pages of applications whose priorities are lower than the demand-paging priority may be paged out.

39. Memory Management Other Basic Operating System Functions Memory Protection: • many real-time operating systems do not provide protected address spaces to the operating system kernel and user processes • QNX and LynxOS operating system support memory protection

40. I/O and networking Other Basic Operating System Functions Three modern features of file system and networking software are: - Multithreaded Server Architecture - Early Demultiplexing - Lightweight Protocol Stack These features were developed to improve the performance of time-shared applications, high-performance applications and network appliances and also real-time applications with enhanced predictability.

41. I/O and networking Other Basic Operating System Functions Multithreaded Server Architecture: • Servers in modern operating systems are typically multithreaded. • In response to a request, server activates (or creates) a work thread to service the request. • This work thread can be prioritized so that it minimizes the duration of priority inversion and can better account for the CPU time consumed by the server while serving the client.

42. I/O and networking Other Basic Operating System Functions Early Demultiplexing • Traditional protocol handlers are based on layered architectures. They can introduce a large blocking time. Because much of the work of protocol module is done before the identity of the receiver becomes known, it cannot be correctly prioritized. • By identifying the receiver of each message (i.e., demultiplexing incoming messages), the duration of priority inversion can be reduced and controlled. • Once the receiver is known, the execution of the protocol modules can be at the priority of the receiver. • Traditionally, incoming messages are first moved to the buffer space of the protocol modules. They are then copied to the address space of the receiver. Early demultiplexing also makes it possible to eliminate the extra copying.

43. I/O and networking Other Basic Operating System Functions Lightweight Protocol Stack • Protocol processing can introduce large overhead and long latency, when the protocol stack has the client/server structure. • Each higher-level protocol module uses the services provided by a protocol module at a layer below. This overhead can be reduced by combining the protocol modules of different layers into a single module and optimizing the module whenever possible. • Scout operating system is used to provide lightweight, low overhead protocol processing. Scout is based on the Path abstraction. A path is a bidirectional virtual connection (channel) which cuts through the protocol layers in a host to connect a source and a sink of data to the network.

44. I/O and networking Other Basic Operating System Functions Lightweight Protocol Stack • Scout uses paths to speed up the data delivery between the network and applications. • At configuration time, a path consisting multiple stages is created one stage at a time starting from one end of the path. • A stage is created by invocating the function pathCreate( ) on the router specified by one of the arguments of the function. • At run time, each path is executed by a thread. • Scout tries to minimize the time for priority inversion by giving each router a demultiplexing operation.

45. Commercial Real Time Operating Systems • Run on common processors and have sizable user bases • Example: - LynxOS - pSOSystem - QNX - VRTX - VxWorks

46. Commercial Real Time Operating Systems • These operating systems are similar in many respects. Summary of their commonalities: - Conformance to Standards: The operating system is compliant or partially compliant to the Real-Time POSIX API standard. The operating system also has its own set of API functions, which may differ significantly from the corresponding POSIX functions. - Modularity and Scalability: The kernel is small, and the operating system configurable. The operating system can be scaled down to fit with the application in ROM in small embedded systems. - Speed and Efficiency: Most of these operating systems are microkernel systems. These microkernel operating systems have low runtime overhead. Important timing figures such as context-switch time, interrupt latency, semaphore get/release latency, and so on, are typically small - System Calls: Nonpreemptable portions of kernel functions necessary for mutual exclusion are highly optimized and made as short and deterministic as possible.

47. Commercial Real Time Operating Systems - Split Interrupt Handling: The nonpreemptable portion of interrupt handling and the execution times of immediate interrupt handling routines are kept small. - Scheduling: All real-time operating systems offer at least 32 priority levels, which is the minimum number required to be Real-Time POSIX compliant; most offer 128 or 256 (or 255). They all offer the choice between FIFO or round-robin policies for scheduling equal-priority threads. - Priority Inversion Control: This system provides priority inheritance and may also provide ceiling-priority protocol. - Clock and Timer Resolution: The operating system may provide a nominal timer resolution down to nanoseconds. - Memory Management: The operating system may provide virtual-to-physical address mapping but does not do paging. - Networking: The operating system can be configured to support TCP/IP, streams, and so on.

48. LynxOS Commercial Real Time Operating Systems • LynxOS 3.0 moves from the monolithic architecture of earlier versions to a microkernel design. The microkernel is 28 kilobytes in size and provides the essential services in scheduling, interrupt dispatch, and synchronization. • LynxOS can be configured as a self-hosted system. In such a system, embedded applications are developed on the same system on which they are to be deployed and run. • LynxOS not only provides memory protection through hardware Memory Management Units (MMUs) but also offers optional demand paging • In LynxOS, application threads (and processes) make I/O requests to the I/O system via system calls such as open( ), read( ), write( ), select( ), and close( ) that resemble the corresponding UNIX system calls.

49. pSOSystem Commercial Real Time Operating Systems • pSOSystem is an object-oriented operating system. • The classes of pSOSystem objects include tasks, memory regions and partitions, message queues, and semaphores. Each object has a node of residence, which is the processor on which the system call that created the object was made. An object may be global or local. • In pSOSystem, device drivers are outside the kernel and can be loaded and removed at run time. When an interrupt occurs, the processor jumps directly to the interrupt service routine pointed to by the vector table. • pSOSystem allocates to tasks memory regions. A memory region is a physically contiguous block of memory. Like all objects, it may be local (i.e., strictly in local memory) or global (i.e., in a systemwide accessible part of the memory).

50. QNX Commercial Real Time Operating Systems • QNX is one of the few multiprocessor operating systems suitable for real-time applications that requires high-end, networked SMP machines with gigabytes of physical memory. • QNX is a message-passing operating system. Messages are delivered in priority order and the service provider executes at the priority of the highest priority clients waiting for service. • QNX implements POSIX message queues outside the kernel but implements QNX’s message passing within the kernel. QNX messages are sent and received over channels and connections.