Components of RTOS

(Or how can RTOS do what it does)

Let’s look at a typical Real Time system implementation.


The RTOS component of the real time system is just the micro kernel part, the yellow region. The RTOS just exports a set of basic components as part of the OS, a priority based task scheduler, a minimalistic memory management subsystem, a set of timers, some task synchronization facilities like semaphores and conditional variables and any other such OS services. The timers and synchronization facilities trigger the scheduler almost everytime. If time slicing is implemented, timer also issues a regular tick which causes currently running tasks to be preempted and next higher priority task to be rescheduled.

As one can notice, the memory space is linear, often physical address space. The execution domain is single, no user – kernel modes of execution. The device drivers are just tasks or threads of execution running at higher priority, as can be seen above. From the RTOS perspective, tasks are often just threads of execution.

Let’s try to look at each of the subsystem and components.

The scheduler is usually a simple round robbin scheduler with priorities. Usually, the scheduler maintains a set of task queues, number depending upon the number of priorities supported. If a system supports 16 priorities for the tasks, the scheduler usually maintains multiples of 16 task queues, each task is queued in one of it’s priority queues. The task queues might consist, at least, ready to run and sleeping. Some relatively simple OS may choose to have single queue for both ready to run and sleeping tasks. Even simpler systems support very minimal priorities, e.g. 4 priorities, maintain a single queue for all the tasks in all states. However, such systems should have very minimal number of tasks, otherwise the scheduler may end up eating all the CPU cycles.

Almost every kernel subsystem invokes the scheduler. A timer event, a semaphore or mutex release and in some cases even an ISR return can invoke the scheduler. The scheduler scans for the next highest priority task to be run. If a new higher priority task came up in running queue, the current task is put to sleep and the newer one starts executing. The scheduler can be locked out by the tasks running critical code, but any use of such facility should be reviewed and reviewed again with every caution. Otherwise, the system may enter deadlock, behavior may become unpredictable or the system may fail to meet the requirements.

If the time slicing is configured and enabled, even the tasks running at the same priority may be preempted to run next task in the same priority queue. At the timer event for time sclicing, the current task is appended at the end of the current priority run queue and the next task is picked up, only after ensuring no higher priority tasks are ready to run.

The task priorities are one of the serious issues which tend to give nightmares to the designers. However, a system with properly decided task priorities runs almost bullet proof. I personally witnessed unstabilities during the development of real time systems without proper calculated/assigned priorities, till the task priorities achieve their perfect balance. From that point, the development, testing and deployment is just a walk in the park.

The memory manager, often, tends to be a simple slab allocator and collector. It is designed to be as simple as possible. Most often, a typical RTOS tends to have a linear physical address space exported to all of it’s tasks. No segmentation, no logical addressing or virtual addressing and paging. Some RTOS tend to provide such facilities, though the tasks utilizing such facilities may be guaranteed to meet real time performance goals. The address space or memory for the memory manager is allocated at the compile time itself. Often, the stack get’s it’s own space allocation and the heap it’s own. In some cases, the stack for a new task is also allocated from the heap and in such cases, the memory manager might need to do a little extra job.

Timer are one integral part for any given RTOS. The timers, in my view, are the heart beat for the RTOS. Without timer events, achieving real time performance is really hard, though not impossible.

Timer subsystem can be broadly divided in to two parts, the timer event generation part and the timer queues. The timer event generation part, usually, depends on the timer device driver for the specific platform. Once the system is up and running, the timer events are genenrated as configured during the compile time. Timer events, often in milliseconds resolution, can either invoke the scheduler or the timer queue management part. If the timer queue management part is invoked, all the timer queues are scanned for the events that need to be shuffled, e.g. task sleeping on a condition, the tasks that have expired timers are added to the respective priority run queue and the scheduler is invoked. Often, different hardware timers are used for time slicing and timer queue management.

The timer subsystem can also cause event posting to the tasks, that a given task can subscribe to. A task can subscribe to timer events at a perticular interval, as per compile time configuration, and can receieve timer events at the configured intervals. Software watchdog systems are one best example. A software watchdog can kill and restart a task or even reset a system if it didn’t receive a predefined event within given time from the given task or subsystem.

The RTOS may also export other subsystems such as system management, interrupt management, libraries for application and even POSIX compliant libraries. Some RTOS may even come with predefined tasks such as for networking or TCP/IP stack and filesystem management tasks.

Let’s look at device drivers, hardware interaction and user task related stuff in the next post.


Real Time Operating Systems – A view from the shore

The Real Time Operating System from a common man’s perspective.

Computing systems can broadly be classified in to Generic computing systems, Embedded computing systems and High performance computing systems. The line  between generic computing systems such as desktop computing systems and the embedded computing systems is getting blurred day by day.

An operating system functions to be the mind of a given computing system. It creates and manages jobs, it deals with allocating and managing resources and much more. Often operating systems come bundled with user interfaces and programmer friendly libraries.

While desktop operating systems can be complex monsters, embedded operating systems usually tend to be much simpler and lighter. As modern embedded systems became much more powerful than earlier general purpose computing systems, the desktop operating systems such as Windows and Linux are finding their way in to embedded computing space, mostly in their miniature forms.

The embedded operating systems can be classified between real-time (RTOS) and non real-time systems. The non real-time systems can further be divided in to two further classes, round-robbin simple kernels and general purpose OS (GPOS) for embedded systems.

The RTOS is the key component in implementing systems with predictable responses. Imagine a mobile processing system, which has a very limited resources such as slow processor and often little RAM and storage facilities. Now, if one does not have a way to implement a predictable behavior software on top of the hardware, the resources are pretty small compred to the job they have to do: process the call data, process the control information, play a song or shoot a picture.

However, RTOS has it’s own set of limitations. First, RTOS cannot, at least at the heart, enforce security such as user/kernel space. Hence, typical RTOS systems cannot run user programs or third party applications. Though there are some exceptions, they run at low priority and consume extra resources. In either case, the application space is limited. Let’s look at that in some other post.

Besides, adding any more tasks can easily change the predictable behavior or the overall system. However, in most cases, the impacted are only the tasks below the new task’s priority. However, since the system is designed to be specific purpose system, complex interdependancies change their equations changing the overall behavior of the system.

On the other hand, a General Purpose Operating System or GPOS, does not have these or other such limitations, which RTOS has. However, GPOS cannot guarantee a predictable execution environment with constrained resources.

Let’s consider the case of a slower PC with Windows or Linux operating system. If you open a file or open the browser while you’re playing a video or even a song in the background, the video or the song will be interrupted for brief durations. In order to be able to run such multiple tasks smooth, the PC should have minimum resources, while a mobile can easily handle such tasks with even minimal resources.

The advantage with embedded GPOS is that it can allow user to build and deploy third party applications without worrying about security or other such issues. That might be the convincing reason behind mulitple processors, often, found in the smart phones.

Let’s take a quick look at RTOS components in the next post.

%d bloggers like this: