<concept id="GUID-7B173E02-9697-51F4-A7E8-795AEF547109" xml:lang="en"><title>Thread Priority Scheme</title><shortdesc>Explains the factors involved in allocating thread priority.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>At any given time, the thread running on Symbian platform is the

one with the highest priority that is ready to run. The priority of

a thread is simply a number; the value determines the priority; the

greater the number, the higher the priority. We call this the <i>true</i> or <i>absolute</i> priority of the thread. </p>

<p>The Kernel schedules a fixed amount of time called a <i>quantum</i> for a thread to run on the CPU, and the scheduler chooses the highest

priority thread that is ready to run. Threads of equal priority are

executed on a <i>round robin basis</i>. </p>

<entry><p>This is reserved for the <i>null thread</i>, which puts

the processor into idle mode to save power when no other threads are

ready to run. </p> </entry>

<entry><p>Used by kernel side threads and user-side applications and

servers </p> </entry>

<entry><p>Used by kernel side threads and protected system servers,

i.e. servers with the <codeph>ProtServ</codeph> capability. </p> </entry>

<image href="GUID-A95FEDD4-106A-5E14-8B64-3E2882C76666_d0e251347_href.png" placement="inline"/>

<section id="GUID-0194B574-806B-5BA3-B65C-6DC5A80CAB86"><title>Priority

scheme for general user-side threads</title> <p>User-side threads

do not allocate <i>true</i> priority values directly. Instead, they

allocate priorities using symbolic values defined by enums. Symbian

platform maps these values to the <i>true</i> value. </p> <p>There

</ul> <p id="GUID-B9022468-F4E7-536B-B1D4-58DAA9EA5914"><b>Process-relative

scheme</b> </p> <p>This scheme bases the <i>true</i> priority of a

thread on the priority of its owning process and the priority of the

thread relative to the process. This means that changing the process

priority results in a change to the <i>true</i> priority of the thread. </p> <p>A process can be assigned one of eight discrete priorities represented

by the individual enumerators of <xref href="GUID-5D289F30-2C88-396D-9748-798055F0AF56.dita"><apiname>TProcessPriority</apiname></xref>, and range from <xref href="GUID-9B7922A7-6098-3BBD-9ADE-BC21AD6381C3.dita"><apiname>EPriorityLow</apiname></xref>, the lowest, to <xref href="GUID-A35268D0-7EFC-3D58-8C79-E4E619F762F5.dita"><apiname>EPrioritySupervisor</apiname></xref>, the highest. </p> <p>In practice, <i>user processes</i> can only be assigned priorities that are one of

the values: </p> <ul>

</ul> <p>There are a further four process priorities that a user process

is not permitted to set: <codeph>EPriorityWindowServer</codeph>, <codeph>EPriorityFileServer</codeph>, <codeph>EPriorityRealTimeServer</codeph> and <codeph>EPrioritySupervisor</codeph>. </p> <p>A process priority

can be assigned: </p> <ul>

<li id="GUID-CC4FA12C-BFDD-5F75-BC18-B742BCACEECF"><p>when the associated <filepath>.exe</filepath> is built; this is done by specifying the value in

the <filepath>.mmp</filepath> file that defines the project. </p> </li>

<li id="GUID-B86220D9-B10D-5506-AD90-73E7F8D7A089"><p>by calling <xref href="GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695.dita#GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695/GUID-189A64CB-F2EA-3C8F-A7A7-01CBF8FDE67A"><apiname>RProcess::SetPriority()</apiname></xref> and passing one of the <xref href="GUID-5D289F30-2C88-396D-9748-798055F0AF56.dita"><apiname>TProcessPriority</apiname></xref> enum values. </p> </li>

</ul> <p>The priority of a thread <i>relative</i> to

a process is assigned by calling <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-8E412361-AE54-3585-AF2A-45D4A53F8B03"><apiname>RThread::SetPriority()</apiname></xref> and passing one of the five <xref href="GUID-8708AFB7-92CC-34FC-9FBB-E6B16472B99D.dita"><apiname>TThreadPriority</apiname></xref> enum

values: </p> <ul>

</ul> <p>The <xref href="GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita#GUID-7B173E02-9697-51F4-A7E8-795AEF547109/GUID-F5B98A28-EEDA-58BD-A6CC-62C1621D44DF">thread priority value mapping table</xref> shows the <i>true</i> priority

of a thread based on the combination of process priority and process-relative

thread priority </p> <p id="GUID-7A38EE63-E955-5432-84E1-F35CB45C931E"><b>Process-independent

scheme for general user threads</b> </p> <p>In this scheme, the <i>true</i> priority of a thread is independent of the priority of its

owning process. Changing the priority of the underlying process has

no effect on the <i>true</i> priority of the thread. </p> <p>The priority

of a thread is assigned by calling <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-8E412361-AE54-3585-AF2A-45D4A53F8B03"><apiname>RThread::SetPriority()</apiname></xref> and passing one of the <xref href="GUID-8708AFB7-92CC-34FC-9FBB-E6B16472B99D.dita"><apiname>TThreadPriority</apiname></xref> enum values

listed below. Note that the set of enum values splits into two logical

groupings based on their equivalence to process-relative values. See

the <xref href="GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita#GUID-7B173E02-9697-51F4-A7E8-795AEF547109/GUID-F5B98A28-EEDA-58BD-A6CC-62C1621D44DF">thread priority value mapping table</xref>. </p> <table id="GUID-A0397BB8-AAC7-5F79-B94F-68103B66132C">

</table> <p>The <xref href="GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita#GUID-7B173E02-9697-51F4-A7E8-795AEF547109/GUID-F5B98A28-EEDA-58BD-A6CC-62C1621D44DF">thread priority value mapping table</xref> shows the resulting <i>true</i> priority of the thread. </p> </section>

<section id="GUID-23801A52-4E62-56F4-8D81-E0A417517FDA"><title>Priority

scheme for real-time user-side threads</title> <p>This scheme is the

same as the <xref href="GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita#GUID-7B173E02-9697-51F4-A7E8-795AEF547109/GUID-7A38EE63-E955-5432-84E1-F35CB45C931E">process-independent scheme for general user threads</xref>, but with

one essential difference - the range of <xref href="GUID-8708AFB7-92CC-34FC-9FBB-E6B16472B99D.dita"><apiname>TThreadPriority</apiname></xref> enum values to be passed to <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-8E412361-AE54-3585-AF2A-45D4A53F8B03"><apiname>RThread::SetPriority()</apiname></xref> is as shown below. These priorities map to the <i>true</i> priority

values in the range 24 -31, and can only be set by executables having

the <codeph>ProtServ</codeph> capability. This range is referred to

as the real time range. </p> <ul>

</ul> <p>The <xref href="GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita#GUID-7B173E02-9697-51F4-A7E8-795AEF547109/GUID-F5B98A28-EEDA-58BD-A6CC-62C1621D44DF">thread priority value mapping table</xref> shows the resulting <i>true</i> priority of the thread. </p> </section>

<section id="GUID-F5B98A28-EEDA-58BD-A6CC-62C1621D44DF"><title>Thread

priority value mapping table</title> <p>This table shows the effect

of setting priorities, and the resulting <i>true</i> priority values.

You need to be aware that this may change in the future, and you should

never synchronise threads on the basis of thread priorities. If you

need to synchronise threads, use mutexes or semaphores. </p> <p>Notes </p> <ul>

<li id="GUID-CBC69A23-E3EF-56BC-A915-2770EBFB76C4"><p>True priority

values in the shaded region can only be accessed by threads running

in processes with the <codeph>ProtServ</codeph> capability. </p> </li>

values : <xref href="GUID-972ADC0C-546E-3D24-9071-02B074DC1540.dita"><apiname>EPriorityWindowServer</apiname></xref>, <xref href="GUID-A19C5464-A1DA-3EEC-B81B-41690EBB3DB2.dita"><apiname>EPriorityFileServer</apiname></xref> and <xref href="GUID-A35268D0-7EFC-3D58-8C79-E4E619F762F5.dita"><apiname>EPrioritySupervisor</apiname></xref> all map to the same range

of priorities. Along with <xref href="GUID-AAA610A8-48D8-3642-94E8-6C9747170DA9.dita"><apiname>EPriorityRealTimeServer</apiname></xref>, these have historically been used for system servers and other

processes needing access to high priorities suitable for real-time

tasks, and their use requires <codeph>ProtServ</codeph> capability. </p> </li>

<li id="GUID-3256F08A-AD30-5378-BFA9-140688B1CDB6"><p>Note that <codeph>ProtServ</codeph> capability will not be granted to general applications

for the purpose of gaining access to the very high thread priorities.

This risks breaking important system functionality. </p> </li>

<image href="GUID-B9306D01-1DE5-511A-AC1A-6E3E9749BA89_d0e251942_href.png" placement="inline"/>

</fig> <p>Note that we have used <i>E'</i> as an abbreviation for <i>EPriority</i> in this diagram. </p> </section>

<section id="GUID-E9AFB6A3-ED3E-5110-82C8-E5E15E0AF899"><title>Platform

security notes</title> <p>Platform security restrictions prevent thread

and process priorities from being modified by another user process.

There is one exception: by default, applications have “Priority Control”

enabled for them which allows the window server to switch them between

foreground and background process priorities depending on which has

foreground focus. </p> </section>