Selecting a plural form for RTOS is hard; there is no one right way. Some possibilities, listed in order of increasing popularity (on the Web), include RTOS’s, RTOSes, and RTOSs. The first implies a possessive aspect that’s clearly not appropriate, so that variant is best avoided. Between the other two, the vast majority of trade journals have adopted RTOSes as their preferred style. Though, apparently, not everyone is yet convinced.
In addition to trying to standardize the language readers use to communicate with one another, an important role of trade journals is helping spread useful new techniques and best practices quickly. For example, numerous articles and columns in past issues of Embedded Systems Programming have helped popularize the use of RTOSes. Approximately half of that magazine’s subscribers now use a commercial RTOS to get the job done.
Unfortunately, however, most of the differentiation between the hundred or so RTOS vendors is on the price and support side, leaving embedded programmers 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, work very well in certain real time systems with high degrees of both parallelism and periodicity. Telecom and datacom products, with their many communication channels, are often of this type.
But the tradeoffs, including increased interrupt latency and potential priority inversions, are significant. Though it can be made to fit some, the static-priority preemptive solution just doesn’t fit the needs of a large population of systems quite right. Some tasks are periodic, but many others are not. 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 quite well for hard real-time systems with harmonic deadline periods and a small number of things to get done. And state machines can be executed in a series of run-to-completion steps via a framework like that 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; many software designs are, in fact, harder with preemption. 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 technique. Just as there are currently various ways of pluralizing RTOS, there are also various ways of doing without one.