What guarantees do "soft" real-time operating systems actually provide

Question

I think I know what a "hard" real-time operating system is. It is an operating system with a scheduler that provides a contract with the application programmer. An application provides a deadline with each resource allocation request. If the deadline requests are feasible, the scheduler guarantees that each resource will be allocated to the requesting application before the deadline. The guarantee is sufficient to enable an application programmer to reason about the maximum latencies and minimum throughputs of specific requests.

All the definitions I find of "soft" real-time systems seem vacuous to me. Wikipedia says

the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

Uhhhh. Okay. By that criteria Windows 95 was a soft real time system and so was 3BSD and so is Linux. Wikipedia is not a great source, but the next couple of Google hits aren't much better. For example http://users.ece.cmu.edu/~koopman/des_s99/real_time/ says

In a soft real-time system, a degraded operation in a rarely occurring peak load can be tolerated.

That's not a contract, that's a fancy way of saying nothing.

What are examples of real soft real-time guarantees/contracts offered by real operating systems?

I'm looking for answers of the form:

In (OS-name) if programmer does (what-programmer-needs-to-do) then the operating system guarantees (what-the-system-guarantees).

Answer 1

You've got it right, and Wikipedia is as informative as can be — soft real-time is not a formal characterization, it's a value judgement. Another way to say “soft real-time” is “I wish it was real-time”, or perhaps more accurately “it should be real-time but that's too hard”.

If you really want to word in the form of a guarantee, it's a guarantee of best effort rather than a guarantee of specific performance.

Or, to quote the Erlang FAQ (Erlang is a programming language originally designed for use in telephony):

What does soft realtime mean?

Cynics will say "basically nothing".

(…) Many telecomms systems have less strict requirements [than hard realtime], for instance they might require a statistical guarantee along the lines of "a database lookup takes less than 20ms in 97% of cases". Soft realtime systems, such as Erlang, let you make that sort of guarantee.

And this does provide a useful definition. Soft real-time indicates a design which is optimized towards each individual task taking no more than a certain amount of time, rather than towards optimizing the total time spent to perform all tasks. For example, a soft real-time system would aim to complete 99.9% of the requests in 10ms and process 100 requests per second, where a non-real-time might aim to proceed 200 requests per second but allow the occasional request to block for 50ms or more. A hard real-time would guarantee one request every 15ms no matter what.

Soft real-time is used for applications where a missed deadline means a degradation of service, but is not performance-critical. Multimedia and telephony are some typical use cases. Each audio or video frame must be rendered it time, or else it has to be skipped; but skipping a frame is not the end of the world. The designers of Erlang had similar objectives on reliability in other matters: they observed that it was better for a telephone exchange to very occasionally drop a call, but to be absolutely sure that the exchange as a whole would keep working come what may, than to ever risk catastrophic failure in trying to maintain connections at all cost.

In contrast, something like controlling a motor requires that the software never misses a deadline. This has costs: the overall performance is typically slower, and only relatively simple behaviors can be achieved. On the other side of the spectrum, a number crunching application typically cares only about overall performance — what matters is how fast the 1000x1000 matrices are multiplied, not how fast each column is calculated.

Answer 2

Linux with the -rt (real time) patchset provides a scheduler that provides an interesting guarantee that seems non-vacuous. (Although I'm not clear on how the guarantee can be put to real use.)

The Linux-rt SCHED_FIFO scheduling policy works as follows: The user assigns a priority to every process. (The priority numbers for "real time" processes are 0-99, and the traditional Unix nice values -20 through 19 map to priorities 100 through 139. (So "0" is the "highest" priority and "139" is the "lowest" priority.)

The guarantee is that at any time the scheduler will schedule the N highest priority runnable jobs on an N processor machine. Great pains have been taken to avoid priority inversion problems inside the kernel. When process A becomes runnable and it has a higher priority than some other running process B, A will immediately preempt B.

Note, though, that there are no strict time guarantees given. The time spent actually performing the preemption could theoretically be arbitrarily long. Also, there do seem to be some ways in which a low priority job could initiate a bunch of long latency i/o. When the i/o completes the interrupt handlers for the low priority job could interrupt a higher priority job, which is, arguably, a form of priority inversion.

So the limited guarantee provided is: if there is a single process with the highest priority, whenever it is runnable it will get all the processor resources that the OS can realistically give it. If you have a good upper limit on the amount of processor resources consumed by the highest priority process you can calculate a reasonably accurate estimate of the resources that will be available to the second-highest priority process, and so on.

An in depth article describing the Linux real-time scheduler is http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler.

Answer 3

To define "soft real-time," it is easiest to compare it with "hard real-time."

Speaking casually, most people implicitly have an informal mental model that considers information or an event as being "real-time"

• if, or to the extent that, it is manifest to them with a delay (latency) that can be related to its perceived currency

• i.e., in a time frame that the information or event has acceptably satisfactory value to them.

There are numerous different ad hoc definitions of "hard real-time," but in that mental model, hard real-time is represented by the "if" term. Specifically, assuming that real-time actions (such as tasks) have completion deadlines, acceptably satisfactory value of the event that all tasks complete is limited to the special case that all tasks meet their deadlines.

Hard real-time systems make the very strong assumptions that everything about the application and system and environment is static and known a' priori—e.g., which tasks, that they are periodic, their arrival times, their periods, their deadlines, that they won’t have resource conflicts, and overall the time evolution of the system. In an aircraft flight control system or automotive braking system and many other cases those assumptions can usually be satisfied so that all the deadlines will be met.

This mental model is deliberately and very usefully general enough to encompass both hard and soft real-time--soft is accommodated by the "to the extent that" phrase. For example, suppose that the task completions event has suboptimal but acceptable value if

• no more than 10% of the tasks miss their deadlines
• or no task is more than 20% tardy
• or the average tardiness of all tasks is no more than 15%
• or the maximum tardiness among all tasks is less than 10%

These are all common examples of soft real-time cases in a great many applications.

Consider the single-task application of picking your child up after school. That probably does not have an actual deadline, instead there is some value to you and your child based on when that event takes place. Too early wastes resources (such as your time) and too late has some negative value because your child might be left alone and potentially in harm's way (or at least inconvenienced).

Unlike the static hard real-time special case, soft real-time makes only the minimum necessary application-specific assumptions about the tasks and system, and uncertainties are expected. To pick up your child, you have to drive to the school, and the time to do that is dynamic depending on weather, traffic conditions, etc. You might be tempted to over-provision your system (i.e., allow what you hope is the worst case driving time) but again this is wasting resources (your time, and occupying the family vehicle, possibly denying use by other family members).

That example may not seem to be costly in terms of wasted resources, but consider other examples. All military combat systems are soft real-time. For example, consider performing an aircraft attack on a hostile ground vehicle using a missile guided with updates to it as the target maneuvers. The maximum satisfaction for completing the course update tasks is achieved by a direct destructive strike on the target. But an attempt to over-provision resources to make certain of this outcome is usually far too expensive and may even be impossible. In this case, you may be less but sufficiently satisfied if the missile strikes close enough to the target to disable it.

Obviously combat scenarios have a great many possible dynamic uncertainties that must be accommodated by the resource management. Soft real-time systems are also very common in many civilian systems, such as industrial automation, although obviously military ones are the most dangerous and urgent ones to achieve acceptably satisfactory value in.

The keystone of real-time systems is "predictability." The hard real-time case is interested in only one special case of predictability--i.e., that the tasks will all meet their deadlines and the maximum possible value will be achieved by that event. That special case is named "deterministic."

There is a spectrum of predictability; most real-time systems (namely, soft ones) have non-deterministic predictability, for example, of the tasks' completions times and hence the values gained from those events. In general, predictability, and hence value, can be made as close to the deterministic end-point as necessary but at a price which may be physically impossible or excessively expensive (as in combat or perhaps even in picking up your child from school).

Soft real-time requires an application-specific choice of a probability model (not the common frequentist model) and hence predictability model for reasoning about event latencies and resulting values.

Referring back to the above list of events that provide acceptable value, now we can add non-deterministic cases, such as

• the probability that no task will miss its deadline by more than 5% is greater than 0.87.

In a missile defense application, given the fact that in combat the offense always has the advantage over the defense, which of these two real-time computing scenarios would you prefer:

• because the perfect destruction of all the hostile missiles is very unlikely or impossible, assign your defensive resources to maximize the probability that as many of the most threatening (e.g., based on their targets) hostile missiles will be successfully intercepted (close interception counts because it can move the hostile missile off-course);

• complain that this is not a real-time computing problem because it is dynamic instead of static, and traditional real-time concepts and techniques do not apply, so you are not interested in doing R&D for soft real-time.

Despite the various misunderstandings about soft real-time in the real-time computing community (but not in other non-computing fields), soft real-time is very general and powerful, and potentially very complex compared with hard real-time.

To directly answer the OP question:

• a hard real-time system can provide deterministic guarantees—most commonly that all tasks will meet their deadlines, interrupt or system call response time will always be less than x, etc.—IF AND ONLY IF very strong assumptions are made and are correct that everything that matters is static and known a' priori (in general, such guarantees for hard real-time systems are an open research problem except for rather simple cases)

• a soft real-time system does not make deterministic guarantees, it is intended to provide the best possible analytically specified probabilistic timeliness and predictability of timeliness that are feasible under the current dynamic circumstances, according to application-specific criteria. Obviously hard real-time is a simple special case of soft real-time. Obviously soft real-time's analytical non-deterministic assurances can be very complex to provide, but are mandatory in the most common real-time cases (including the most dangerous safety-critical ones such as combat) since most cases are dynamic not static.

I have a detailed much more precise discussion of real-time, hard real-time, soft real-time, predictability, determinism, and related topics on my web site real-time.org.