Why isn't every OS real-time?

Question

I've heard nothing but good things about RTOSs--they give the programmer greater control over the scheduler so as to e.g. avoid priority inversion, their timing is more consistent, better multitasking. But all standard desktop setups use OSs that aren't real-time. So there must be some tradeoffs to using an RTOS, what are they?

Oogenesis

Answer 1

RTOS typically trade throughput performance and features for predictability and tractability. The usual definition of "real-time" folks apply is "deterministic"; you can't have determinism without paying for it.

In general purpose OS'es, we're motivated by "common-case" behaviors -- we want really good average performance, and a lot of flexibility. In RTOS, we want a reliable ceiling on "worst case" behaviors, and we pay (often dearly) in throughput or common-case behaviors.

Yes, it's possible to create hybrids, like Windows or even Linux real-time threads. But somewhere you're typically paying a penalty because ultimately there is only the finite set of resources available (CPUs, IO bandwidth, whatever) and consumer OS'es and RTOS'es optimize around different criteria. Some of the RT Linux approaches deal with this explicitly, by having partitions. Different assumptions and different optimality criteria are optimized for in each partition.

What features are traded? I can't offer a precise list -- it's more that general-purpose OS'es tend to have a zillion drivers, and be able to keep up with the churn of new devices; RTOS tend to focus on a much smaller set for which timeliness can be either well-understood or explicitly kept from interfering with other activities. You probably won't have the same selection of drivers on a normal RTOS because it's not reasonable to implement them, typically.

Throughput Remember "real-time" != "real-fast". When a system is real-time, it means that activities' time of completion is part of their correctness. In some cases, this means processing many activities very quickly (high throughput); in others it may be processing at a relatively slow but extremely predictable period. The structures in an RTOS may have high throughput, but typically can't achieve the throughput of an equivalent RTOS because the techniques used to achieve that throughput fairly (caching, fancy interactivity-driven scheduling approaches, "fair" queuing and lock contention) militate against predictability of any single task's timeliness.

Deflower

What features are traded? And what do you mean by 'throughput performance', my impression is that what does run on an RTOS runs as fast as it would anywhere. – Oogenesis

Note: Real-time threads aren't really real-time, because they don't have absolute control over processor behavior. :\ They're close, though. – Saleable

@Mehrdad: I agree AND disagree, and that was precisely my point. You can create a hybrid, but you get something a bit different. I'd argue that Win/Linux RT threads are "real-time" in the expansive sense of the term -- they are explicitly focused on timeliness. They are NOT deterministic, as threads in some RTOS are. In my world, "real-time" != "deterministic". – Deflower

@andersoj: I thought realtime = deterministic? – Saleable

@Mehrdad: Many folks operate under that definition, but it is not generally true. It is true that most of the "real-time" academic disciplines and analytical techniques force you into a deterministic mold. However, there are many applications I would consider real-time that tolerate a probabilistic guarantee rather than a deterministic one. The term commonly used for these applications is "soft real-time". I can tolerate an audio stream with a certain statistical amount of jitter; it's "real-time" because the timing matters if the application is going to "work" but it's not deterministic. – Deflower

Some useful information at the real-time tag wiki: stackoverflow.com/tags/real-time/info – Deflower

@andersoj: the real-time tag wiki also says: "The term real-time is sometimes problematic because it implies determinism" (emphasis mine)... I think you mean time-critical instead? – Saleable

@Mehrdad: Also note that, as much as real-time traditionalists like to talk about determinism, it's only their mental and formal models that are truly deterministic. They enforce deterministic assumptions on a stochastic world in order for their real-time models to be applicable. In many cases, these are reasonable assumptions--Newton's laws are deterministic, but we know they don't describe the entire universe. However "deterministic" your RTOS and algorithms are proven to be on paper, they eventually execute in a messy world. Embrace it. ;-) – Deflower

@Mehrdad: I'm taking a position here. Like I admit above, many users of the term "real-time" assert it means determinism. Not all. Those in my field (defense) who build lots of RT systems on RTOS don't use it in that way. Other related disciplines (aviation or industrial automation) almost always mean determinism when they say real-time (but they are living a convenient fiction). However, there is an entrenched industrial and academic viewpoint that does. There's no ultimate authority to appeal to on what the term means, I guess -- it means what it's used for, which is not consistent. – Deflower

@andersoj: Huh, okay; thanks for the info. I wish there was a common definition for these... :) – Saleable

I'd claim the wiki tag's definition is a good one (I wrote it, at least an earlier version of it): A task is *real-time when the timeliness of the activities' completion is a functional requirement and correctness condition, rather than merely a performance metric. A real-time system is one where some (though perhaps not all) of the tasks are real-time tasks.* That does not (to me) imply deterministic. – Deflower

No, real-time doesn't mean determinism, insofar as it requires an upper bound on timing, not fixed timing. But things like disk caching and interactive priority boost also mess with upper bounds. – Comitative

@Deflower I'm a bit confused here. If the timeliness of a task is a correctness condition, and to you that does not imply determinism (of the timeliness of the task), then you seem to be arguing that the reason it does not imply determinism is that the system is not guaranteed to be correct? But by that definition, the outcome of an add instruction isn't deterministic either, because the CPU is not guaranteed to be correct. It could be faulty, for instance. – Jodee

Answer 2

I'm not sure if this is a big reason, but I believe the existence of non-realtime features like System Management Mode in the processor doesn't really allow for a real-time OS, because SMM can take as arbitrarily long as it wants to respond to an SMI, and the best the OS can do is just time out and crash when it gains back control -- if it gains back control in a timely manner. So you'd need the BIOS to be realtime as well, which is not quite as easy as having just one company like Microsoft make its OS realtime (which isn't easy by itself anyway).

And there probably wouldn't be too much gain for the average user, anyway.

Saleable

Thanks--but this doesn't jump out as something that should be a dealbreaker. Surely you could create a highest-priority process in an RTOS and use it do all the things listed under 'Usage' in the wikipedia page. – Oogenesis

@Matt: It would involve a huge architectural change on the part of (1) processor companies like Intel/AMD, (2) OS makers like Microsoft, (3) BIOS makers like Phoenix, AMI, etc., (4) makers of every other kind of device that can issue a high-priority interrupt, (5) lots of software companies. It's possible, but the costs would likely outweigh the benefits. – Saleable

Answer 3

Features that help with desktop application development just aren't important in applications that require a real-time OS. So RTOS vendors tend to focus their engineering time on things that are important to their customers, like fast booting and error recovery.

Until there's a market for overlap between rapid application development and real-time, you're unlikely to see an OS vendor split its resources between both. Rapid development and safety-critical just don't go together.

With the Blackberry Playbook moving to QNX, we might see for the first time a friendly development environment (libraries as well as tools) for an RTOS.

Comitative

"Until there's a market for overlap between rapid application development and real-time, you're unlikely to see an OS vendor split its resources between both." I guess my problem is that I don't understand the extent to which these are mutually exclusive. What's an example of a RAD-friendly feature that would appear in a standard desktop OS that wouldn't be acceptable for an OS? – Oogenesis

@Matt: They aren't unacceptable in an RTOS, they're unacceptable in a safety-critical application which represents nearly all RTOS licensees. Why would an RTOS vendor spend time on say porting Visual Basic for Applications, (or mono or a JVM) to their OS, when its nature restricts it from ever being used by the majority of their customers. – Comitative

I guess this is the sort of thing I don't understand--why can't you run JVM under an RTOS? – Oogenesis

@Matt: You could, if you ported one... but it doesn't help the people who buy RTOSes, since it's not validated sufficiently for use in a safety-critical system. So why spend the time and money to port one? You could develop a fully validated JVM I guess, but then your competitors who spent their time doing something their customers were asking for would have a huge competitive advantage. – Comitative

@Ben Voigt: A number of real-time JVMs exist... #4052466 including one from aicas that I believe can achieve DO-178B validated/certified. – Deflower

Also, WindRiver has a JVM for vxworks -- I'm not sure how well supported it is, but I've seen it in some room automation systems. – Deflower

@andersoj: Ok, you have a JVM. Now do you have JavaBeans, AWT, Swing, jogl, jdbc, and all the myriad of other libraries that make Java developers productive on desktop OSes? Maybe a couple, definitely not all. Why? Same reason -- porting effort required, and most RTOS customers don't care. – Comitative

@Ben: Sure, you're right. Just making the point that there is enough demand for RT Java that at least JVMs exist with reasonable timeliness properties. But your larger point (the same as I made elsewhere) is accurate -- the RT environment typically has fewer features and options because there is not demand and the cost of implementation/porting is much higher in the RT arena. Not to mention that RT designers tend to get paranoid about unnecessary complexity. – Deflower

Answer 4

It is basically the same reason as "why doesn't everyone write webapps in C?". Its a lot faster, but, it is much more difficult. RTOSs on a large system becomes unwieldy because a lot of the control is given to the application programmer.

Panorama

I've never programmed to a RTOS--what about it would make it harder? You can assume more control, but do you have to? Qt exists for both non-RT and RTOSs, there are some differences but not many. – Oogenesis

Qt abstracts away a TON of stuff for you to feel happy in an RTOS. – Panorama

I can't find the page now, but the Nokia site listed a number of features you didn't get with Qt for QNX and the only major one I recall was no QProcess. (Maybe no Phonon either, or something like that.) – Oogenesis