The Distinction Between Conventional and Real-time Multi-tasking

In a strict sense, real-time refers to applications that have a time critical nature. Consider a data acquisition and control program for an automobile engine. Assume that the data must be collected and processed once each revolution of the engine shaft. This means that data must be read and processed before the shaft rotates another revolution, otherwise the sampling rate will be compromised and inaccurate calculations may result. Contrast this with a program that prints payroll checks. The speed at which computations are made has no bearing on the accuracy of the results. Payroll checks will be generated with perfect results regardless of how long it takes to compute net pay and deductions.

A Conventional Definition of Real-time

The term real-time has evolved to refer to any application in which a computer is used to control a process. Machine control; robotics; data acquisition and display; communications; telephone systems; automotive control systems; factory automation and instrumentation systems are a few examples.

Soft Real-time vs. Hard Real-time

Hard real-time refers to the strict definition of real-time as given in the automotive example above. That is, time critical situations in which errors can occur if timing requirements are not met. As mentioned above, the definition of real-time has evolved to refer to any application in which a computer is used to control a process, some of which do not have hard real-time constraints, and these are referred to as soft real-time applications. A data acquisition and display application in which readings are periodically taken and displayed is an example of a soft real-time application. Although there may be a desired sample and display rate of 500 ms, errors will not result if the sample rate is not accurately met. The worst that can happen is that samples are not displayed as quickly as desired, but the point is that no errors can result. Soft-real-time applications can typically be handled by robust conventional multi-tasking kernels.

Real-time Multi-tasking vs. Conventional Multi-tasking

Since real-time applications are typically involved with controlling more than one process, multi-tasking has become an integral part of real-time systems. Multi-tasking is typically done using the cyclical executive approach or a variation thereof. However, for more demanding applications a real-time multi-tasking kernel or real-timeOS is used. (See the article When does it Make Sense to use a Real-time Kernel? for deciding which approach to take.)

Real-time multi-tasking kernels must provide the following: (1) a fast and predictable means of switching to a high priority task, (2) a means of switching to a high priority task from within an interrupt service routine, (3) task priorities and a means for honoring priorities in a real-time manner. Any multi-tasking kernel that does not provide these features is not a real-time multi-tasking kernel and will be referred to in this article as a conventional multi-tasking kernel. These features will be elaborated upon below.

The Need for Predictability and Isr Task Switching

Before discussing this topic it should be made clear that ultra time-critical applications cannot afford the overhead introduced by a real-time multi-tasking kernel. Ultra time-critical applications typically use the cyclical executive approach to cycle through routine tasks and time-critical jobs are handled inside isr's. However, most real-time applications can probably handle the small overhead introduced by a good real-time kernel.

Predictability

Consider the automotive example given above. Let us assume the following: (1) the shaft takes 50 ms to complete one revolution, (2) at the start of each shaft revolution an interrupt is generated at which point the system must take various readings that take a total of 30 ms, (3) the readings must be completed before the next interrupt, (4) the readings must be done by a task, (referred to below as taskA), not the isr.

(Note that in the following discussion some timing parameters have been left out for the sake of clarity. For details, please send us e-mail.) The total processing time must be less than 50 ms, or the system requirements will not be met. The total time processing is: the time it takes for taskA to take readings and process data + system overhead. The system overhead is: hardware interrupt latency (typically negligible) + isr processing time. The isr processing time is: the time it takes to enter and exit the isr (assume this is negligible) + the time required to schedule taskA so that when the isr executes the IRET instruction, control will return to taskA. So, the total processing time between shaft revolutions is:

1. the time it takes for taskA to take readings and process data, plus,
2. the time required to schedule taskA

We can compute item 1, and for this example, let us assume that item 1 takes 30 ms. Item 2 is a bit more difficult to compute. We can contact the kernel supplier and ask them, but this will still be inaccurate, since the actual time is processor, clock, and hardware dependent. The easiest thing to do is to run the software, and see if it gets the job done within the 50 ms window.

The key point to be understood is that item 2 must be predictable and repeatable, otherwise, a worst case time for item 2 cannot be known, and the system may or may not work properly. For example, if the time for item 2 is typically 1 ms, but can vary to more than 1 second, then the kernel is not acceptable, and furthermore, it is not a real-time kernel, because of its unpredictability.

Isr Stack Switching

As indicated above, when the isr is entered, it is important that the isr not return to the task that was interrupted, but rather to the higher priority task, taskA. Without this feature, the isr would only have the ability to schedule taskA; the IRET instruction would return to the interrupted task (call it taskB), and taskA would not run until taskB decided to relinquish control. (Conventional kernels may also use other techniques, although they are unacceptable. For example, a high priority kernel task can run periodically to check if any user tasks have been scheduled that are of a higher priority than the active task, and if so, switch to the higher priority task, but of course, this is not a time responsive solution.)

Priorities

It is evident from the discussion above, that real-time systems require priorities, otherwise, tasks would simply run in turn, and no priority based preemption would be allowed. Even simple message passing should honor priorities. For example, if taskB sends taskA a message, and taskA is of a higher priority, then when taskB calls sendMsg to send the message to taskA, the message will be sent, after which taskB will suspend so that higher priority taskA (which was presumably asleep waiting for a message) can run and receive the message. It should also be noted that the mere presence of priorities does not mean that the kernel features real-time priorities as described above. For example, a time-sharing multi-user system that uses fairness as its scheduling policy is not real-time, even though it may use priorities. For more information about priorities, please see the article Assigning Task Priorities.

Concluding Remarks

Although there are other features that are useful and often present in real-time kernels, the distinguishing features of a real-time kernel are basically those outlined above, namely predictability, priorities, and the ability to switch to a task from within an isr.

We welcome comments. Let us know what subjects you would like written up. Send comments to mike@Ticsrealtime.com