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 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

OS Structures 9/18/2018

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 9/18/2018

OS Structures 9/18/2018

OS Structures 9/18/2018

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 9/18/2018

OS Structures Benefits Problems 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 9/18/2018

OS Structures 9/18/2018

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 9/18/2018

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 9/18/2018

OS Basics Interprocess Communication Memory Management 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 9/18/2018

RTOS Basics 9/18/2018

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 9/18/2018

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.) 9/18/2018

RTOS Basics 9/18/2018

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 9/18/2018

RTOS Basics Max number of threads, tasks or processes Definition space part of system A system parameter Definition space part of task Available memory 9/18/2018

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 9/18/2018

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 9/18/2018

Basic Facilities 9/18/2018

Basic Facilities 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

Interrupts RTOSs vary in model of interrupt handling to task run 9/18/2018

Interrupts Interrupt Dispatch Time Interrupt Routine Other Interrupt 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 9/18/2018

Interrupts Scheduling Context Switch Return from System Call 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 9/18/2018

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 9/18/2018

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 9/18/2018

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 9/18/2018

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) 9/18/2018

Memory Static memory allocation Dynamic 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 9/18/2018

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 9/18/2018

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) 9/18/2018

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 9/18/2018

Development Methodology Resource and hardware shared May prevents RTOS from predictable behavior May prevent GPOS from housekeeping duties Multiprocessor environment should improve performance 9/18/2018

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 9/18/2018

Summary HRT SRT NRT Mem Allocation Static Dynamic/Static Dynamic Virtual Memory No Yes Compaction 9/18/2018

Summary VxWorks QNX Development Methodology Host  Target POSIX Compatibility Most 1003.1b API for C – POSIX.1 File Systems MS-DOS, RT-11, raw disk, SCSI, CD-ROM Ramdisk (Unixlike), MS-DOS Shared Memory Objects VxMP (semaphores, message queues, memory regions between tasks on different processors) Shared memory between processes, shared files Virtual Memory VxVMI – support for boards with MMU ??? Debugging Target Agent – remote debugging GNU 9/18/2018

Summary VxWorks QNX Multitasking Process-task based Interrupt-driven, priority-based task scheduling, round-robin 256 priority levels (0-255); 0 highest, 255 lowest May be set dynamically Process-thread based Priority-based, round-robin, FIFO (cooperative), adaptive (decaying) 32 priority levels (0-31); 0 lowest, 31 highest Semaphores Counting, binary, mutual-exclusion (recursive), and POSIX, timeouts Memory based Intertask Communications Message queues (priority or FIFO), pipes, sockets, signals, RPCs Messages (copied), queues (FIFO), pipes, sockets, signals, proxies 9/18/2018

Summary VxWorks QNX Priority inversion Yes – tasks that owns a resource executes at the priority of the highest priority task blocked on that resource Yes – receiving processes will float to higher level priority of sending processes Asynchronous I/O Yes “Yes” – FIFO queue/pipe 9/18/2018

Summary VxWorks QNX Context Task Program counter CPU registers (optional Floating point) Stack I/O assignments (STD Out, In, Err) Delay Timer Timeslice timer Kernel Control Structures Signal Handlers Debugging and performance monitoring values Memory address space is not part of context (VxVMI is required for separate address space per task – virtual to physical memory mapping Process Program counter CPU registers I/O assignments 9/18/2018

Summary VxWorks QNX States Ready – Not waiting for any resource except CPU Pend – Blocked, waiting on resource Delay – Asleep for some duration Suspend – Unavailable for execution Delay + S – Delayed & suspended Pend + S – Pended & suspended Pend + T – Pended with timeout value Pend + S + T – Pended, suspended with timeout value State + I – state plus an inherited priority Ready – Running or waiting to run Blocked – waiting on resource - Send Blocked – sent message not received yet - Receive Blocked – waiting to receive - Reply Blocked – waiting on reply - Signal Blocked – reply-blocked process is interrupted by a signal - Semaphore Blocked – waiting on a semaphore Wait – Waiting on child to terminate Dead – Terminated but has not sent status to parent Held – Suspended by another process 9/18/2018

Summary VxWorks QNX Interrupts Run in special context outside of task (no task context switch) Share single stack if architecture allows (must be large enough for all possible nested interrupt combinations) Must not invoke routines that may cause the caller to block (taking semaphores, I/O calls, malloc, and free) Must not call routines that use FP-coprocessor (floating point registers are not saved and restored); otherwise must explicitly save and restore FP registers SWI – signals HWI – ISRs implemented in device drivers which are a part of the system kernel 9/18/2018

References “What Makes A Good RTOS”, RTOS Evaluation Program, Real-Time Magazine, Version 2.0, 28 February 2000. Y. Li, M. Potkonjak and W. Wolf, “Real-Time Operating Systems for Embedded Computing”, Department of Electrical Engineering, Princeton University, Department of Computer Science, UCLA, IEEE 1997. F. Kolnick, QNX 4 Real-time Operating System: Programming with Messages in a Distributed Environment, Basic Computer Systems Inc., 1998. “VxWorks Guide”, WindRiver Systems. 9/18/2018