Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Real-Time OS In Today's World

Sebastien Marineau-Mes is vice president of engineering for QNX Software, where he is responsible for all QNX R&D activities. Sebastien has also served as the first project lead for the Eclipse C/C++ Development Tools (CDT) project.

DDJ: Sebastien, over 25 years ago, QNX Software Systems focused on the message-passing paradigm for its operating-system solutions. Are message-passing operating systems relevant today?

SM: If anything, the qualities of isolation and protection introduced by the message-passing paradigm are more important now than they were 25 years ago. Take, for example, the issues of OS reliability and security. (By security, I mean protection from external attacks as well as from "bad" code running in the system.) Both these issues pose a huge challenge to traditional OSs, which lump large amounts of unrelated functionality, including file systems, networking stacks, and device drivers, into a single, large monolithic kernel. In this approach, coding errors in one block can easily affect a totally unrelated block, resulting in total system failure.

A microkernel, message-passing OS eliminates these problems by completely isolating applications and traditional kernel functional blocks from one another. With this approach, the OS can immediately detect an invalid attempt to access resources and indicate what line of code made the attempt. At runtime, a software watchdog can intelligently decide how to handle the error. This can range from a simple "prevent the access but let the functional block continue" to "completely stop and restart the function block." Either way, the OS and all other processes continue to run.

DDJ: One of the areas you've been working on recently is support for multi-core processors. What is the role of multi-core in the embedded world?

SM: The growing complexity of embedded applications has created four major hardware issues: performance, power consumption, board area, and cost. Multi-core chips directly address all four issues. They offer greater processing capacity and consume less power than conventional uniprocessor chips, and they use less board space (which cuts costs) than multiprocessing systems built of discrete uniprocessors.

Nonetheless, migrating legacy code to multi-core can be a challenge. That's why QNX offers a choice of multiprocessing models, allowing developers to choose the model best suited to their requirements. For instance, we support symmetric multiprocessing (SMP) for applications optimized for multi-core operation; we've also pioneered bound multiprocessing (BMP), which lets legacy applications run on a specified core while allowing parallelized applications to run in full SMP mode.

DDJ: Another area that you've been working on is "adaptive partitioning." What is it and why is it important?

SM: Some OSs support time partitioning, which lets you place applications into partitions and allocate a guaranteed budget of CPU time to each partition. Unfortunately, traditional partitioning schemes are very rigid. For instance, if you allocate a partition 30 percent of CPU time, it will always consume 30 percent, even when processes in that partition have no work to do.

That's why we created QNX Neutrino adaptive partitioning. Unlike conventional schemes, it maximizes CPU utilization by distributing a partition's unused CPU cycles among partitions that could benefit from the extra CPU time.

Adaptive partitioning lets you contain denial-of-service (DoS) attacks and eliminate single points of failure. For example, in a nonpartitioned real-time system, a single, high-priority thread can maliciously or inadvertently monopolize the entire CPU; nothing else gets to run. But with adaptive partitioning, threads in other partitions can still get their guaranteed share of system resources, even if they run at a lower priority than the runaway thread.

DDJ: Real-time and embedded systems have become much more pervasive over recent years, particularly in terms of consumer's everyday lives. Cell phones, MP3 players, automotive electronics, home appliances, and the like. Is it a challenge to support all of these disparate, small-footprint devices for an OS company?

SM: The componentized nature of QNX technology makes it much easier to support a wide array of systems. For example, the exact same USB stack used in a home appliance can also run in an automotive head unit. All system testing done on that stack is immediately inherited when it is used in other devices.

Wherever possible, we also abstract hardware dependencies from middleware components, allowing, for example, a system integrator to run the same Adobe Flash player on a home appliance as on a PND. This approach allows for greater reusability without forcing massive code rewrites or intensive retesting.

DDJ: Many OS vendors have embedded features such as security and databases into the OS kernel, which makes you think that as devices get smaller, the software to support them gets larger. Is that the case?

SM: Most OSs don't have efficient models for adding system services outside of the kernel. So, if you want code to run fast and to be easily accessed by other services and applications, you must stick it in the kernel. This leads to two options: 1) creating many different kernels for different product lines, or 2) using the same larger kernel across many products. The first approach leads to much more testing; the second approach forces lower-end products to incur higher RAM and ROM costs.

QNX microkernel architecture helps to streamline the device footprint. Most OS services run as optional components that load and unload on demand; they're never "linked" to the kernel. The result is a consistent, reliable software foundation where the same kernel can be used across all product lines.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.