Explains the factors to consider when choosing real time thread priority.
Hard real-time tasks must complete within a fixed amount of time otherwise they fail.
Audio playback provides a good example of a hard real-time task. During audio playback the soundcard driver reads data from an audio buffer to transfer to the soundcard. The audio application uses a thread to re-fill this buffer before it empties, and failure to do this before the deadline causes an audible break in the sound.
Telephony applications are another example of hard real-time tasks.
Symbian platform gives no real-time scheduling guarantees to user processes. Instead, system threads such as those running device drivers are designed to be efficient and well behaved for their priorities. The following list gives the estimated deadline ranges other threads are likely to meet reliably for a given priority on a busy system:
These figures rely on real-time threads completing their work in less time than the deadline itself, otherwise other threads may fail to meet their deadlines. These deadline ranges appear conservative because they are based on what is a achievable on a busy system. Use of lower true priorities than those in the above table are recommended whenever the implications of failing to meet a deadline are not very serious and the incidence of failure is acceptably low in practical testing.
Soft real-time tasks try to complete within a fixed amount of time. In contrast to hard real-time, exceeding this time is not considered a failure, although it may affect the user experience in some way.
Soft real-time tasks generally have a quality of service target expressed as a percentage that is less than 100% (where 100% represents hard real-time). This value is the percentage of tasks that must complete within the deadline to satisfy the expected service levels. Usually the programmer implements a recovery strategy to cope with a thread missing the deadline.
Examples of soft real-time tasks include the responsiveness of the system to user events and communications protocols. In the case of responsiveness to user events, an arbitrary deadline is aimed for that is ‘close enough to instantaneous’; in the case of communication protocols, failure to process data in time causes it to be retransmitted – possibly at extra cost to the user – but is otherwise not a catastrophic failure.
When developing real-time code follow these rules:
Do the minimum amount of work required to meet your deadline at the required priority.
For hard real-time tasks, use the lowest priority you can to achieve your goals within the task deadline.
Avoid using lower priority, non real-time services, for example file I/O in high priority threads. This sacrifices the benefit of using a high priority real-time thread.
For soft real-time tasks choose a priority above which no significant performance differences are observed once the required service level is met.
For typical applications that respond to user interaction, soft real-time priorities start at values based on the EPriorityAbsoluteForegroundNormal process priority, but are more often based on the EPriorityHigh process priority.
For tasks that will use all available CPU by the sheer frequency that the thread is scheduled (for example, using a very high bandwidth communication channel, or achieving high/maximum frame rates in an action game), lower priorities should be used; this includes priorities based on the EPriorityAbsoluteForegroundNormal process priority.
Escalating priorities for soft real-time tasks into the levels normally used for hard real-time tasks is dangerous.