How -to Choose a Real-time Thread Priority

Real-time categories
Guidelines for writing real-time code

Real-time categories

Real-time -tasks divide into two categories:

Hard real-time
Soft real-time

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

- - - -

Deadline range

True thread priority value

- - -

> 100ms

24-26

- - -

> 20ms

- - -

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.

Guidelines -for writing real-time code

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.

+ + + + + +How +to Choose a Real-time Thread PriorityExplains the factors to consider when choosing real time thread +priority. +

Real-time categories
Guidelines for writing real-time code

Real-time categories

Real-time +tasks divide into two categories:

Hard real-time
Soft real-time

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

+ + + +

Deadline range

True thread priority value

+ + +

> 100ms

24-26

+ + +

> 20ms

+ + +

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.

Guidelines +for writing real-time code

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.

\ No newline at end of file