Selecting a plural form for the acronym RTOS is hard; there's no one right way to spell it. Some possibilities, in order of increasing popularity on the Web, include RTOS's, RTOSes, and RTOSs. The first implies a possessive, which is clearly not appropriate and should be avoided. Between the other two, the majority of trade journals, including this one, have RTOSes as their preferred style.
In addition to trying to standardize jargon, trade journals help spread useful new techniques and best practices quickly. For example, numerous articles and columns in Embedded Systems Programming have certainly helped popularize the use of RTOSes. Approximately half of our subscribers now use a commercial RTOS to get the job done.
In that vein, here's a new concept: life after RTOSes. Because the main differences between the hundred or so RTOS vendors are on the price and support side only, embedded programmers are left to develop their own solutions when a preemptive priority-based scheduler doesn't fit the problem at hand. In fact, as RTOS vendors continue to argue against “rolling your own” and worry about lower-cost or no-cost competitors, I would argue that most are overlooking the technically obvious.
Static-priority preemptive schedulers, with priorities assigned rate or deadline monotonically (see this month's Web exclusive for more on the latter algorithm), work well in certain real-time systems with high degrees of both parallelism and periodicity. Telecom and datacom products, with their many communication channels, often benefit from this type of architecture.
But the tradeoffs, including increased interrupt latency and potential priority inversions, are significant. The static-priority preemptive solution-while it can be made to fit some systems-doesn't fit the needs of all systems. Some tasks are periodic, but many others are not. (See “Scheduling Sporadic Events,” for a way of dealing with aperiodicity.) Some systems have hard deadlines, but many others do not-or can safely miss a few now and then. In such cases, other types of multitasking (or even the lack thereof) may be preferable to the much-touted RTOS.
Alternative ways of structuring embedded software run the gamut from simple main()+ISR implementations to the use of dynamic priorities. For example, a simple executive is a low-overhead technique that works well for hard real-time systems with harmonic deadline periods and a small number of jobs to get done. And state machines can be executed in a series of run-to-completion steps via a framework like the one outlined in Miro Samek's excellent book Practical Statecharts in C and C++ (CMP Books). Taking another approach, Java and Ada support threads natively, making the choice of a particular RTOS largely irrelevant.
My point? The hundred-plus commercial RTOSes available today have too much in common technically. Not every embedded designer benefits from adding a static-priority preemptive scheduler. RTOS vendors might do better to view themselves as providers of software frameworks for developing embedded software-and differentiate themselves by offering more than one. Just as there are several ways of pluralizing RTOS, there are also several reasonable ways of doing without one.