Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


How to choose a real-time thread priority

[Top]


Real-time categories

Real-time tasks divide into two categories:


Hard real-time

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 OS 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:

Deadline range

True thread priority value

> 100ms

24-26

> 20ms

27

2-20ms

28-31

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

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.

[Top]


Guidelines for writing real-time code

When developing real-time code follow these rules: