Scheduling and Thread Management with RTEMS Gedare Bloom Joel Sherrill Dept. of Computer Science OAR Corporation George Washington University Huntsville, AL Washington, DC [email protected] [email protected] ABSTRACT 1. INTRODUCTION The goal of a real-time operating system (RTOS) is to support An operating system is a collection of software services and ab- real-time and embedded system (RT/ES) application development, straction layers that enable applications to be concerned with busi- which differ from general-purpose applications because of the size, ness logic rather than the specifics of device control and protocol weight, and power (SWaP) and timing constraints imposed by em- stacks. With this abstraction of lower level concerns, the applica- bedded applications. Useful RTOS features include real-time thread tion can be portable across hardware platforms. Operating system scheduling, thread communication, synchronization, interrupt han- standards such as IEEE POSIX define operating systems interfaces dling, memory management, file systems, device drivers, network- which enable applications to be portable from one operating system ing, and debugging support. The Real-Time Executive for Multi- implementation to another. processor Systems (RTEMS) is a free and open-source RTOS that supports over a dozen processor architecture families and over 150 A real-time operating system (RTOS) is an operating system de- embedded system boards. RTEMS is designed to support embed- signed to provide applications services which assist in meeting ap- ded applications with stringent real-time requirements while being plication requirements which including timing. These timing re- compatible with open standards such as POSIX. RTEMS includes quirements are typically related to interaction with external de- optional services such as TCP/IP networking and file systems while vices, other computers, or humans. For example, a sensor may still offering minimum executable sizes under 20 KB in useful con- need to be sampled every fifty (50) milliseconds or the data is cor- figurations. rupt. Airline reservation systems have been classified as real-time systems because their requirements specify that a user request must One of the primary functions of an RTOS is to select threads that be responded to within a specific amount of time. Even though this can obtain access to resources such as shared memory and proces- response time is specified in seconds rather than milliseconds this sor time. RTEMS uses multiple algorithms to manage both waiting still meets the definition of real-time. These timing requirements threads and those ready to execute. The thread execution schedulers impose deadlines on the behavior of the application. include the traditional RTOS round robin and deterministic priority schedulers, rate monotonic, earliest deadline first (EDF), constant Real-time applications may further be divided into soft real-time, bandwidth server (CBS), and simple SMP scheduling algorithms. hard real-time, and safety critical based upon the negative impact The RTEMS scheduling framework allows the application devel- of missing a deadline. If missing a single deadline can be com- oper to select the thread scheduling algorithm that best meets the pensated for and has little impact, the deadline is considered soft. application’s space and time requirements. ÂaWe˘ will present how Missing multiple soft deadlines may or may not have severe conse- this framework can be used by researchers to integrate their own quences. In contrast, a hard deadline is one which must be met or scheduling algorithm into RTEMS and test it using a scheduling negative consequences occur. Many hard deadlines may be further simulator before deploying it on target hardware. classified as safety critical in case missing the deadline may result in harm to persons or property. An example of a common safety Categories and Subject Descriptors critical real-time system is an anti-lock brake system. Computer Systems Organization [Real-time systems]: Real-time Use of an operating system decouples the application from the operating systems hardware platform and provides a core set of resource management services. Operating systems provide services such as concurrency, Keywords memory management, file systems, and networking. Relying on Scheduling, RTEMS operating systems allows applications to be developed quicker and at lower costs. This provides faster time to market and reduces the likelihood of reengineering required if the application must be rehosted on a different hardware platform. An RTOS provides all of the advantages of a non-real-time oper- ating system while adding determinism. Determinism ensures that the operating system is designed to perform actions with bounded EWiLi ’13 August 26–27, 2013, Toulouse, FRANCE response times for arbitrary inputs. For example, the time required Copyright retained by the authors. to block or unblock a single thread is independent of the number of threads created by the application. Although there are many RTOSes available and there are great dif- ferences between them, there are a common set of features found in most of them. First, they are designed to handle real-time con- straints correctly and provide services to the application to enable this. They provide a multi-threaded environment usually including preemptive, priority-based scheduling often with timeslicing capa- bility. This is sufficient to implement applications based on the rate monotonic scheduling algorithm [7], and some RTOSes provide ex- tra services for periodic threads and statistics gathering to further assist such applications. Since RTOSes provide multi-threaded environments, they must also provide mechanisms for those threads to communicate and syn- chronize. Although the application programming interface (API) and specific details may differ, it is common for RTOSes to pro- vide some combination of message queues, semaphores, mutexes, Figure 1: Dependency tree for an architectural port in RTEMS. events, and condition variables to coordinate threads. Other thread communication and synchronization mechanisms include barriers, asynchronous signals, and read/write locks. RTOSes with mutexes such as the LM32 and NIOS2. Figure 1 shows the dependencies of typically offer algorithms to avoid priority inversion, such as the a typical architectural port for RTEMS. priority ceiling or priority inheritance protocols [9]. Being a free, open-source project means that all RTEMS source RTOSes may provide various types of memory management ser- code is available to the user for inspection, analysis, tailoring, and vices. It is common to have the RTOS provide support for the redistribution. RTEMS does not include software for the target C program heap used by the malloc family as well as for spe- hardware with any licenses that impose obligations on the licens- cial purpose memory pools. These special purpose memory pools ing of the user’s application. In the following, we summarize the may be managed using variable or fixed allocation schemes. Some primary components of RTEMS before we discuss the RTEMS RTOSes provide memory management unit interfaces which can scheduling framework in the next section. Extra details are avail- be used to denote that certain areas of memory are read-only, exe- able in the RTEMS manuals that are included with the RTEMS cutable, or not to be cached. source code [5] and are provided online for convenience [3]. Although modern personal computers tend to have x86-compatible 2.1 API Layers processors and a common hardware architecture, target hardware From a technical perspective, RTEMS provides a single-address for embedded real-time applications can vary enormously. There space, multi-threaded environment for applications. Historically are dozens of microprocessors available for this market and thou- applications have been statically linked, but now RTEMS supports sands of boards. Many real-time applications also include custom dynamic loading of code with the RTEMS Dynamic Loader project. designed boards. RTOSes need to provide a design framework Still, the user’s application, BSP, and RTEMS all reside in the same to support such wide variety—the board support package (BSP) address space. framework. A BSP will include hardware initialization, device drivers, bus adapters, and interrupt controller management. Given To limit the complexity of applications, RTEMS uses a layered the wide variety of embedded hardware, it is important for individ- software architecture with the Classic, POSIX, and SAPI inter- ual device drivers to be shared across boards. Some RTOSes in- faces; the ITRON interface has been dropped during the 4.11 re- clude many BSPs as part of their standard deliverable, while other lease series. The Classic API was based upon the RTEID and RTOS vendors license individual BSPs. ORKID RTOS API standards, which were proposed but never stan- dardized by the VMEBus Industry Trade Association. RTEMS sup- RTOSes are often very modular so that unused features can easily ports a large subset of POSIX 1003.1b through the POSIX API, be left out of a system. This has the technical benefit of allowing which is POSIX-compliant for the features of POSIX that are nec- real-time applications to be fielded in lower end target hardware essary for single-user, single process applications. SAPI (“sappy”) and the business benefit of allowing some RTOS vendors to sell exposes features such as initialization, configuration, user exten- those capabilities as extra-cost items. Some