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.)
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.
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.
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.)
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.
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
Copyright © 1992-2004, Tics Realtime