How -to Choose Thread Priority

The two main considerations when choosing the priority of a thread are: -the timing requirements of the task that the thread must accomplish, and the -other tasks that are likely to be running at the same time.

Choosing a process priority
Choosing the priority of a thread relative to a process
Choosing a process-independent thread priority
Guideline summary
Long running background tasks
Special timing requirements

Choosing a -process priority

Choose one of the four standard process priorities -listed below as the basis for a range of relative priorities:

EPriorityForeground

This -is the default process priority. Use this priority for:
- The currently selected -user interface application which appears in the foreground on the device screen. -This application is said to have the focus.
- Servers that do not -have specific timing or response requirements.
The UIKON framework calls User::SetPriorityControl (ETrue) so -that the window server can switch applications to background when not in focus. -This is known as priority control. The application can further specify -how the window server makes the priority change using RWsSession::ComputeMode(). -However, applications should not disable priority control to run permanently -at EPriorityForeground process priority without strong justification. Priority -control is irrelevant to processes without a user interface, for which -it should remain disabled.
EPriorityBackground

Use -this process priority for:
- all running user interface -applications except the currently selected application. These applications -appear in the background on the device screen.
- applications which do -not need to respond rapidly to user actions. For example applications that -do not have a graphical user interface.
EPriorityHigh

Use -this process priority for system servers which should respond quickly to client -requests. These servers must do minimal work at this priority level before -quitting to allow other threads to run.
EPriorityLow

Use -this priority for processes which can run in the background.
The remaining priority -values:EPriorityWindowServer,EPriorityFileServer, EPrioritySupervisor and EPriorityRealTimeServer can only be used by processes with ProtServ (Protected -Server) Security Capability.

See Process-relative -scheme in Priority -scheme for general user-side threads in Thread -priority scheme.

Choosing the -priority of a thread relative to a process

EPriorityNormal is -the default relative thread priority. Choose EPriorityLess and EPriorityMuchLess to -set a lower priority than the owning process. Choose EPriorityMore and EPriorityMuchMore to -set a higher priority than the owning process.

Application programs -and system servers with no special -timing requirements running with a process priority of EPriorityForeground or EPriorityBackground should -use the default relative priority EPriorityNormal for -their main thread.

Choosing a -process-independent thread priority

Use process-independent thread -priorities only when strictly required. Typically, this is when the -thread's behaviour means that its priority must lie outside the range of relative -priorities available with a chosen process priority. Such threads are used -for tasks with special -timing requirements, such as long running background tasks or time -critical tasks.

Avoid "absolute" priorities in the middle of the range -of relative priorities available with the chosen process priority. For example, -consider what happens if you use EPriorityAbsoluteForegroundNormal. -This is in the middle of the range of priorities relative to the EPriorityForeground process -priority. If the process priority is changed to EPriorityBackground, -then the thread will now pre-empt all threads that have been assigned process-relative -priorities.

Time critical tasks can be divided into those that must -complete as quickly as possible and those that need to complete within a fixed -time interval. The former are simply high priority tasks, the latter are known -as real-time tasks. See How -to choose a real-time thread priority.

Guideline summary

Use process-relative -thread priorities instead of process-independent thread priorities whenever -possible.
Only use process-independent -thread priorities for threads that need to run at particularly high or low -priorities compared to other threads running on the system. Examples of these -two extremes are short term, time critical tasks or long running background tasks.
Ensure that threads -with priorities above EPriorityAbsoluteForegroundNormal such -as the GUI foreground application and system servers do not perform long-running -tasks.
Ensure that threads -with priorities in the range above EPriorityAbsoluteBackgroundNormal, -and below or equal to EPriorityAbsoluteForegroundNormal do -not perform long-running tasks.
Threads can have equal -priorities. Higher or lower priorities are only needed if one thread must -pre-empt another.
GUI applications must -not disable priority control to run permanently at EPriorityForeground process -priority without very good reason. See also choosing -a process priority for a description of priority control.
Unless there is a specific -requirement, disable priority control for processes without a user interface.
Avoid adding unnecessary -extra functionality to high priority threads. Instead, create a new lower -priority thread for this code. Always perform the minimum work at a given -priority to meet a task deadline.
Never assume a higher -priority thread will run before a lower priority thread. The scheduling algorithm -and the thread -priority value mapping table might change. Use a synchronization mechanism -such as a semaphore or mutex to guarantee that a thread is not interrupted.
Always avoid unnecessary long -running background tasks as this reduces battery performance.
Devices only have a -finite amount of processing power. The full impact of choosing a particular -thread priority is often only observed when the system is under stress, causing -some tasks to succeed at the expense of others. This can only be discovered -through appropriate stress testing.
When testing new software -use realistic scenarios. Run applications which are likely to be used at the -same time as the new code, for example making and receiving calls at the same -time as sending a text message. Adjust thread priorities as necessary to ensure -a good end-user experience. Choosing too high a priority for your software -can adversely effect the end-user's experience just as severely as using a -priority which is too low.

Long running -background tasks

Long running tasks usually run in the background. -They use a low priority thread and do not directly respond to user interaction. -They generally use all the CPU time available to them and run for a period -of a fraction of a second to a few seconds. Occasionally long running tasks, -critical to the currently selected UI application, run at a higher priority -for a few seconds.

Special timing -requirements

Tasks with special timing requirements fall into two -distinct categories:

Short term, time critical -tasks.

These use high priority or real-time threads.
Long running background -tasks such as garbage collection and other cleanup tasks.

These use -low priority threads.

+ + + + + +How +to Choose Thread PriorityExplains the factors to consider when choosing a thread priority. +

The two main considerations when choosing the priority of a thread are: +the timing requirements of the task that the thread must accomplish, and the +other tasks that are likely to be running at the same time.

Choosing a process priority
Choosing the priority of a thread relative to a process
Choosing a process-independent thread priority
Guideline summary
Long running background tasks
Special timing requirements

Choosing a +process priority

Choose one of the four standard process priorities +listed below as the basis for a range of relative priorities:

EPriorityForeground

This +is the default process priority. Use this priority for:
- The currently selected +user interface application which appears in the foreground on the device screen. +This application is said to have the focus.
- Servers that do not +have specific timing or response requirements.
The UIKON framework calls User::SetPriorityControl (ETrue) so +that the window server can switch applications to background when not in focus. +This is known as priority control. The application can further specify +how the window server makes the priority change using RWsSession::ComputeMode(). +However, applications should not disable priority control to run permanently +at EPriorityForeground process priority without strong justification. Priority +control is irrelevant to processes without a user interface, for which +it should remain disabled.
EPriorityBackground

Use +this process priority for:
- all running user interface +applications except the currently selected application. These applications +appear in the background on the device screen.
- applications which do +not need to respond rapidly to user actions. For example applications that +do not have a graphical user interface.
EPriorityHigh

Use +this process priority for system servers which should respond quickly to client +requests. These servers must do minimal work at this priority level before +quitting to allow other threads to run.
EPriorityLow

Use +this priority for processes which can run in the background.
The remaining priority +values:EPriorityWindowServer,EPriorityFileServer, EPrioritySupervisor and EPriorityRealTimeServer can only be used by processes with ProtServ (Protected +Server) Security Capability.

See Process-relative +scheme in Priority +scheme for general user-side threads in Thread +priority scheme.

Choosing the +priority of a thread relative to a process

EPriorityNormal is +the default relative thread priority. Choose EPriorityLess and EPriorityMuchLess to +set a lower priority than the owning process. Choose EPriorityMore and EPriorityMuchMore to +set a higher priority than the owning process.

Application programs +and system servers with no special +timing requirements running with a process priority of EPriorityForeground or EPriorityBackground should +use the default relative priority EPriorityNormal for +their main thread.

Choosing a +process-independent thread priority

Use process-independent thread +priorities only when strictly required. Typically, this is when the +thread's behaviour means that its priority must lie outside the range of relative +priorities available with a chosen process priority. Such threads are used +for tasks with special +timing requirements, such as long running background tasks or time +critical tasks.

Avoid "absolute" priorities in the middle of the range +of relative priorities available with the chosen process priority. For example, +consider what happens if you use EPriorityAbsoluteForegroundNormal. +This is in the middle of the range of priorities relative to the EPriorityForeground process +priority. If the process priority is changed to EPriorityBackground, +then the thread will now pre-empt all threads that have been assigned process-relative +priorities.

Time critical tasks can be divided into those that must +complete as quickly as possible and those that need to complete within a fixed +time interval. The former are simply high priority tasks, the latter are known +as real-time tasks. See How +to choose a real-time thread priority.

Guideline summary

Use process-relative +thread priorities instead of process-independent thread priorities whenever +possible.
Only use process-independent +thread priorities for threads that need to run at particularly high or low +priorities compared to other threads running on the system. Examples of these +two extremes are short term, time critical tasks or long running background tasks.
Ensure that threads +with priorities above EPriorityAbsoluteForegroundNormal such +as the GUI foreground application and system servers do not perform long-running +tasks.
Ensure that threads +with priorities in the range above EPriorityAbsoluteBackgroundNormal, +and below or equal to EPriorityAbsoluteForegroundNormal do +not perform long-running tasks.
Threads can have equal +priorities. Higher or lower priorities are only needed if one thread must +pre-empt another.
GUI applications must +not disable priority control to run permanently at EPriorityForeground process +priority without very good reason. See also choosing +a process priority for a description of priority control.
Unless there is a specific +requirement, disable priority control for processes without a user interface.
Avoid adding unnecessary +extra functionality to high priority threads. Instead, create a new lower +priority thread for this code. Always perform the minimum work at a given +priority to meet a task deadline.
Never assume a higher +priority thread will run before a lower priority thread. The scheduling algorithm +and the thread +priority value mapping table might change. Use a synchronization mechanism +such as a semaphore or mutex to guarantee that a thread is not interrupted.
Always avoid unnecessary long +running background tasks as this reduces battery performance.
Devices only have a +finite amount of processing power. The full impact of choosing a particular +thread priority is often only observed when the system is under stress, causing +some tasks to succeed at the expense of others. This can only be discovered +through appropriate stress testing.
When testing new software +use realistic scenarios. Run applications which are likely to be used at the +same time as the new code, for example making and receiving calls at the same +time as sending a text message. Adjust thread priorities as necessary to ensure +a good end-user experience. Choosing too high a priority for your software +can adversely effect the end-user's experience just as severely as using a +priority which is too low.

Long running +background tasks

Long running tasks usually run in the background. +They use a low priority thread and do not directly respond to user interaction. +They generally use all the CPU time available to them and run for a period +of a fraction of a second to a few seconds. Occasionally long running tasks, +critical to the currently selected UI application, run at a higher priority +for a few seconds.

Special timing +requirements

Tasks with special timing requirements fall into two +distinct categories:

Short term, time critical +tasks.

These use high priority or real-time threads.
Long running background +tasks such as garbage collection and other cleanup tasks.

These use +low priority threads.

\ No newline at end of file