How to choose a priority for a thread

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

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

1. 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.

2. 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.

3. 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.

4. EPriorityLow

   Use this priority for processes which can run in the background.

5. 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.

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.

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 prioriities.

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.

• 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 synchronisation 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 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.

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.