1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-49379616-C235-598D-AE43-668998AD072B" xml:lang="en"><title>Process,

    13 Thread, Stack and Memory Attributes</title><shortdesc>Reference for users of the debug monitor tool to the attributes

    14 of Kernel objects and memory structure. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15 <ul>

    16 <li id="GUID-98737E3D-1A08-53ED-89C5-C0398E02C509"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-4D7F6A1F-3120-5547-B027-344C08A01D83">Process and thread priorities</xref>  </p> </li>

    17 <li id="GUID-F08BDD05-90C3-544E-8C41-788A556F799F"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-DDC45F0A-6B62-5EE6-9E42-D21F07BCF4B4">Thread state summary</xref>  </p> </li>

    18 <li id="GUID-5C39B7CB-D8B1-5DD4-BD62-76595A3B2EB4"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-C6296C07-220E-5EB8-9E12-F7D63AB4B181">Thread and process exit information summary</xref>  </p> </li>

    19 <li id="GUID-4F26D9D7-D335-5332-899D-E4DA6D8F4819"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-68CF9014-4922-56B9-9E53-AC5697F60E8E"> Critical threads and processes</xref>  </p> </li>

    20 <li id="GUID-528E13A3-7E35-5153-87D6-C25CD3E90B6E"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-6530D514-A6CC-5AE9-AA97-C223B2189A09">Kernel calls and thread context</xref>  </p> </li>

    21 <li id="GUID-4D0AC539-A105-5D26-896C-E32A2863213B"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-5A573FEB-A274-5C0F-A6B6-87D5BAD8A21C">Stacks</xref>  </p> </li>

    22 <li id="GUID-3A45E908-3D72-5871-9DEB-454F75A084BE"><p> <xref href="GUID-49379616-C235-598D-AE43-668998AD072B.dita#GUID-49379616-C235-598D-AE43-668998AD072B/GUID-E3F102A4-D187-5BC9-BE97-9F8447A5DB45">Virtual memory and run addresses</xref>  </p> </li>

    23 </ul>

    24 <section id="GUID-4D7F6A1F-3120-5547-B027-344C08A01D83"><title>Process and

    25 thread priorities</title> <p>Internally the scheduler always deals with nanokernel

    26 threads, <codeph>NThread</codeph> objects, and their associated priority between

    27 0 (lowest) and 63 (highest). In general, a thread with a higher priority that

    28 is ready to run will always run in preference to threads with a lower priority.

    29 The only exception is where a higher priority thread waits on a nanokernel

    30 fast mutex held by a lower priority thread. In this case, the higher priority

    31 thread will yield to the lower priority thread holding the mutex. </p> <p>A

    32 Symbian platform thread, a <codeph>DThread</codeph> object, has an embedded <codeph>NThread</codeph>,

    33 which enables it to be scheduled by the nanokernel. </p> <p>There are two

    34 ways of setting a priority for Symbian platform thread: </p> <ul>

    35 <li id="GUID-8568544D-49F4-5D52-8E38-28A09058FB04"><p>using the two-level

    36 priority scheme </p> </li>

    37 <li id="GUID-F3D2BAF8-9C95-59C3-A50E-150A7BDA4EE7"><p>using an absolute priority. </p> </li>

    38 </ul> <p><b>The

    39 two level priority scheme</b> </p> <p>In this scheme, a Symbian platform thread

    40 priority is relative to the priority of its owning process. By default, Symbian

    41 platform threads inherit the priority of their owning process when they are

    42 created. This priority can be raised or lowered relative to the process priority

    43 - this just sets the thread’s priority to the process priority plus or minus

    44 a specified priority weighting. If the priority of the process is changed,

    45 the priority of its threads will change relative to other threads in the system

    46 but will remain the same relative to each other. </p> <p>The default priority

    47 of a process is <codeph>EPriorityForgeround</codeph>, which is an absolute

    48 priority of 350. Threads by default are created with relative priority <codeph>EPriorityNormal</codeph> which

    49 sets them to the same priority as the owning process. The window server lowers

    50 the priority of background UI processes to <codeph>EPriorityBackground</codeph> (250). </p> <p>The

    51 NULL thread, also known as the idle thread, runs at priority 0, and means

    52 that it will only run when there are no other threads ready to run. </p> <p>Symbian

    53 platform thread priorities map onto <codeph>NThread</codeph> priorities in

    54 the range 1 to 31 as shown in the table below. </p> <table id="GUID-E61C3B76-B47D-5B9B-A469-A369D5AB4AFC">

    55 <tgroup cols="8"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><colspec colname="col3"/><colspec colname="col4"/><colspec colname="col5"/><colspec colname="col6"/><colspec colname="col7"/>

    56 <tbody>

    57 <row>

    58 <entry><p> <b>Thread priority</b>  </p> </entry>

    59 <entry><p>Idle </p> </entry>

    60 <entry><p>Much Less </p> </entry>

    61 <entry><p>Less </p> </entry>

    62 <entry><p>Normal </p> </entry>

    63 <entry><p>More </p> </entry>

    64 <entry><p>Much More </p> </entry>

    65 <entry><p>Real Time </p> </entry>

    66 </row>

    67 <row>

    68 <entry><p> <b>Process priority</b>  </p> </entry>

    69 <entry><p> </p> </entry>

    70 <entry><p> </p> </entry>

    71 <entry><p> </p> </entry>

    72 <entry><p> </p> </entry>

    73 <entry><p> </p> </entry>

    74 <entry><p> </p> </entry>

    75 <entry><p> </p> </entry>

    76 </row>

    77 <row>

    78 <entry><p>Low </p> </entry>

    79 <entry><p>1</p> </entry>

    80 <entry><p>1</p> </entry>

    81 <entry><p>2</p> </entry>

    82 <entry><p>3</p> </entry>

    83 <entry><p>4</p> </entry>

    84 <entry><p>5</p> </entry>

    85 <entry><p>22 </p> </entry>

    86 </row>

    87 <row>

    88 <entry><p>Background </p> </entry>

    89 <entry><p>3</p> </entry>

    90 <entry><p>5</p> </entry>

    91 <entry><p>6</p> </entry>

    92 <entry><p>7</p> </entry>

    93 <entry><p>8</p> </entry>

    94 <entry><p>9</p> </entry>

    95 <entry><p>22 </p> </entry>

    96 </row>

    97 <row>

    98 <entry><p>Foreground </p> </entry>

    99 <entry><p>3</p> </entry>

   100 <entry><p>10 </p> </entry>

   101 <entry><p>11 </p> </entry>

   102 <entry><p>12 </p> </entry>

   103 <entry><p>13 </p> </entry>

   104 <entry><p>14 </p> </entry>

   105 <entry><p>22 </p> </entry>

   106 </row>

   107 <row>

   108 <entry><p>High </p> </entry>

   109 <entry><p>3</p> </entry>

   110 <entry><p>17 </p> </entry>

   111 <entry><p>18 </p> </entry>

   112 <entry><p>19 </p> </entry>

   113 <entry><p>20 </p> </entry>

   114 <entry><p>22 </p> </entry>

   115 <entry><p>23 </p> </entry>

   116 </row>

   117 <row>

   118 <entry><p>SystemServer1 </p> </entry>

   119 <entry><p>9</p> </entry>

   120 <entry><p>15 </p> </entry>

   121 <entry><p>16 </p> </entry>

   122 <entry><p>21 </p> </entry>

   123 <entry><p>23 </p> </entry>

   124 <entry><p>25 </p> </entry>

   125 <entry><p>28 </p> </entry>

   126 </row>

   127 <row>

   128 <entry><p>SystemServer2 </p> </entry>

   129 <entry><p>9</p> </entry>

   130 <entry><p>15 </p> </entry>

   131 <entry><p>16 </p> </entry>

   132 <entry><p>21 </p> </entry>

   133 <entry><p>23 </p> </entry>

   134 <entry><p>25 </p> </entry>

   135 <entry><p>28 </p> </entry>

   136 </row>

   137 <row>

   138 <entry><p>SystemServer3 </p> </entry>

   139 <entry><p>9</p> </entry>

   140 <entry><p>15 </p> </entry>

   141 <entry><p>16 </p> </entry>

   142 <entry><p>21 </p> </entry>

   143 <entry><p>23 </p> </entry>

   144 <entry><p>25 </p> </entry>

   145 <entry><p>28 </p> </entry>

   146 </row>

   147 <row>

   148 <entry><p>RealTimeServer </p> </entry>

   149 <entry><p>18 </p> </entry>

   150 <entry><p>26 </p> </entry>

   151 <entry><p>27 </p> </entry>

   152 <entry><p>28 </p> </entry>

   153 <entry><p>29 </p> </entry>

   154 <entry><p>30 </p> </entry>

   155 <entry><p>31 </p> </entry>

   156 </row>

   157 </tbody>

   158 </tgroup>

   159 </table> <p>where: </p> <ul>

   160 <li id="GUID-4315CEE2-2717-5E8F-A8F7-885C621A95B6"><p>the process priority

   161 values are defined by the internal Symbian platform enum <codeph>TProcPriority</codeph>,

   162 defined in <filepath>...\e32\include\kernel\kern_priv.h</filepath>. The symbols

   163 in the table correspond to the symbols in the enum. </p> </li>

   164 <li id="GUID-89D0D7FA-4B17-5753-898A-26C1B20EE59B"><p>the thread priority

   165 values are defined by the internal Symbian platform enum <codeph>TThrdPriority</codeph>,

   166 defined in <filepath>...\e32\include\kernel\kern_priv.h</filepath>. The symbols

   167 in the table correspond to the symbols in the enum. </p> </li>

   168 </ul> <p><b>Absolute

   169 priority scheme</b> </p> <p>It is possible to set an absolute priority that

   170 is not relative to the process priority; it is not affected by changes in

   171 the process priority. </p> </section>

   172 <section id="GUID-DDC45F0A-6B62-5EE6-9E42-D21F07BCF4B4"><title>Thread state

   173 summary</title> <p>This is a brief summary about nanokernel thread states

   174 and Symbian platform thread states. </p> <p><b>Nanokernel

   175 thread states</b> </p> <p>The state of a nanokernel thread is referred to

   176 as the NState (or N-state). This is to disambiguate it from any other state,

   177 such as the state of a Symbian platform thread (referred to as the MState

   178 or M-state). </p> <p>The states of a nanokernel thread are defined by the

   179 values of the <xref href="GUID-379D9320-AC3C-3206-8A5D-EE6E5983EBDC.dita#GUID-379D9320-AC3C-3206-8A5D-EE6E5983EBDC/GUID-2184305D-18EF-3322-9276-20F8A4253455"><apiname>NThreadBase::NThreadState</apiname></xref> enumeration. </p> <p><b>Symbian platform thread states</b> </p> <p>The state of a Symbian platform

   180 thread is referred to as the MState (or M_state). This is in addition to the

   181 nanokernel N-state, and tracks threads waiting on Symbian platform synchronization

   182 objects. The <codeph>DThread</codeph> class representing a Symbian platform

   183 thread is internal to Symbian, but the following table defines its possible

   184 states. The values in the left-hand column are the enumerators of the internal

   185 enumeration <codeph>DThread::TThreadState</codeph>. </p> <table id="GUID-C6ACF17D-2E18-5FCB-9383-BAE57D8F420F">

   186 <tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>

   187 <tbody>

   188 <row>

   189 <entry><p> <codeph>ECreated</codeph>  </p> </entry>

   190 <entry><p>The initial state of all Symbian platform threads. It is a transient

   191 state; the thread starts in this state when the <codeph>DThread</codeph> object

   192 is created, and stays in that state until it is ready to be resumed, typically

   193 when DLL linkage and memory allocation is complete. At this point, the state

   194 will change to <codeph>EReady</codeph>. </p> </entry>

   195 </row>

   196 <row>

   197 <entry><p> <codeph>EDead</codeph>  </p> </entry>

   198 <entry><p>This is the final state of a Symbian platform thread. A thread enters

   199 this state when it reaches the end of its exit handler, just before the nanokernel

   200 terminates it. In effect, the thread has exited but has not yet been deleted. </p> </entry>

   201 </row>

   202 <row>

   203 <entry><p> <codeph>EReady</codeph>  </p> </entry>

   204 <entry><p>This indicates that the thread is not waiting on, or attached to

   205 any Symbian platform kernel wait object. It does not necessarily imply that

   206 the thread is actually ready to run - this is indicated by the N-state. For

   207 example, a thread that is explicitly suspended or waiting on a nanokernel

   208 wait object (generally a fast semaphore) still has a READY M-state provided

   209 that it is not attached to any Symbian platform wait object. </p> </entry>

   210 </row>

   211 <row>

   212 <entry><p> <codeph>EWaitSemaphore</codeph>  </p> </entry>

   213 <entry><p>This indicates that the thread is currently blocked waiting for

   214 a Symbian platform semaphore, and is enqueued on the semaphore’s wait queue.

   215 The thread’s <codeph>DThread::iWaitObj</codeph> field points to the semaphore. </p> <p>For

   216 example, this is the case if the thread calls <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-50223158-D05D-33FE-A3DD-FFA9E2F464FF"><apiname>User::WaitForRequest()</apiname></xref> or <xref href="GUID-AED27A76-3645-3A04-B80D-10473D9C5A27.dita#GUID-AED27A76-3645-3A04-B80D-10473D9C5A27/GUID-68F18434-4758-33BA-9959-1F92A50651A2"><apiname>RSemaphore::Wait()</apiname></xref>  </p> </entry>

   217 </row>

   218 <row>

   219 <entry><p> <codeph>EWaitSemaphoreSuspended</codeph>  </p> </entry>

   220 <entry><p>This indicates that the thread has been explicitly suspended after

   221 blocking on a Symbian platform semaphore, and is enqueued on the semaphore’s

   222 suspended queue. The thread’s <codeph>DThread::iWaitObj</codeph> field points

   223 to the semaphore. </p> </entry>

   224 </row>

   225 <row>

   226 <entry><p> <codeph>EWaitMutex</codeph>  </p> </entry>

   227 <entry><p>This indicates that the thread is currently blocked waiting for

   228 a Symbian platform mutex, and is enqueued on the mutex wait queue. The thread’s <codeph>DThread::iWaitObj</codeph> field

   229 points to the mutex. </p> </entry>

   230 </row>

   231 <row>

   232 <entry><p> <codeph>EWaitMutexSuspended</codeph>  </p> </entry>

   233 <entry><p>This indicates that the thread has been explicitly suspended after

   234 blocking on a Symbian platform mutex, and is enqueued on the mutex suspended

   235 queue. The thread’s <codeph>DThread::iWaitObj</codeph> field points to the

   236 mutex. </p> </entry>

   237 </row>

   238 <row>

   239 <entry><p> <codeph>EHoldMutexPending</codeph>  </p> </entry>

   240 <entry><p>This indicates that the thread has been woken up from the EWaitMutex

   241 state but has not yet claimed the mutex. The thread is enqueued on the mutex

   242 pending queue and the thread’s <codeph>DThread::iWaitObj</codeph> field points

   243 to the mutex. </p> </entry>

   244 </row>

   245 <row>

   246 <entry><p> <codeph>EWaitCondVar</codeph>  </p> </entry>

   247 <entry><p>This indicates that the thread is waiting on a condition variable. </p> </entry>

   248 </row>

   249 <row>

   250 <entry><p> <codeph>EWaitCondVarSuspended</codeph>  </p> </entry>

   251 <entry><p>This indicates that the thread is suspended while waiting on a condition

   252 variable. </p> </entry>

   253 </row>

   254 </tbody>

   255 </tgroup>

   256 </table> </section>

   257 <section id="GUID-C6296C07-220E-5EB8-9E12-F7D63AB4B181"><title>Thread and

   258 process exit information summary</title> <p>User threads and processes have

   259 “exit information”. When a thread or process terminates the reason for the

   260 termination is found in the exit information. For example, a panic will store

   261 the panic category and reason in the exit information. Exit information has

   262 three parts: the exit type, exit reason and exit category. </p> <p>Exit type

   263 is defined by the <xref href="GUID-0296BFC6-7F7C-3259-AF21-7E9B5C304B24.dita"><apiname>TExitType</apiname></xref> enum. </p> <p>When a thread

   264 or process is created, its exit type is set to 3. An exit type of 3 indicates

   265 that the thread is still active, though not necessarily running. If the thread

   266 terminates for any reason, then the exit type is changed to reflect the cause

   267 of the exit. </p> <p>Once the thread or process has exited, the exit reason

   268 and exit type fields will contain useful information. The contents depends

   269 on the type of exit. </p> <p>Note that if the main thread in a process exits,

   270 then the process will exit with the same exit information as the thread. </p> <p><b>Exit category: Terminate</b> </p> <p>if <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-CE11A762-AF52-3122-86C8-C2F362AEF764"><apiname>RThread::Terminate()</apiname></xref> or <xref href="GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695.dita#GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695/GUID-3DD41FD4-F389-340F-8E18-8FDEBC953251"><apiname>RProcess::Terminate()</apiname></xref> is

   271 called, then the exit category is <codeph>Terminate</codeph>, and the exit

   272 reason is the value of the <codeph>aReason</codeph> argument passed to these

   273 functions. </p> <p><b>Exit

   274 category: Kill</b> </p> <p>If <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-1F717486-784A-32B9-A048-EE4F2450F8C8"><apiname>RThread::Kill()</apiname></xref> or <xref href="GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695.dita#GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695/GUID-8E87D3AE-E3F0-34DD-98C6-71B0D0D55FB8"><apiname>RProcess::Kill()</apiname></xref> is

   275 called, then the exit category is <codeph>Kill</codeph>, and the exit reason

   276 is the value of the <codeph>aReason</codeph> argument passed to these functions. </p> <p><b>Exit category: panic</b> </p> <p>If a thread panics, then the exit category

   277 is <codeph>panic</codeph>, and the exit reason is the panic number. For example

   278 a USER-19 panic would give the following exit information: </p> <codeblock id="GUID-ACC94269-E06E-5C7F-ACAF-74764FE21A0F" xml:space="preserve">exit type = 2

   279 exit category = “USER”

   280 exit reason = 19

   281 </codeblock> </section>

   282 <section id="GUID-68CF9014-4922-56B9-9E53-AC5697F60E8E"><title> Critical threads

   283 and processes</title> <p>Marking a thread or process as “system critical”

   284 means that it is an integral and essential part of the system, for example,

   285 the file server. In effect the thread or process is being declared necessary

   286 for correct functioning of the device. If a system critical thread exits or

   287 panics then the device will reboot; during development it will enter the debug

   288 monitor. A thread can be set as process critical, which means that if it panics

   289 the process will be panicked. </p> </section>

   290 <section id="GUID-6530D514-A6CC-5AE9-AA97-C223B2189A09"><title> Kernel calls

   291 and thread context</title> <p>When a user thread makes a call into any kernel

   292 code, the kernel code continues to run in the context of the user thread.

   293 This applies to device driver code. </p> <p>The stack is swapped to a kernel-side

   294 stack and the permissions of the thread are increased to kernel privilege,

   295 but otherwise the user thread is still running. Each thread has a small kernel

   296 stack used to handle kernel calls – it would be dangerous to continue using

   297 the normal thread stack in case it overflows. Some calls are handled in this

   298 state, others – typically device drivers – will post a message to a kernel

   299 side thread to carry out the request. </p> </section>

   300 <section id="GUID-5A573FEB-A274-5C0F-A6B6-87D5BAD8A21C"><title>Stacks</title> <p>When

   301 a process is created, a chunk is allocated to hold the process executable's <codeph>.data</codeph> section

   302 (initialised data) and <codeph>.bss</codeph> section (zero filled data). Sufficient

   303 space (default 2Mb) is also reserved as user-side stack space for threads

   304 that run in that process. </p> <p>By default, each thread is allocated 8k

   305 of user-side stack space. A guard of 8k is also allocated. </p> <p>The stack

   306 area follows the <codeph>.data</codeph> and <codeph>.bss</codeph> sections,

   307 and each thread's user side stack follows. On ARM processors the stack is

   308 descending, so that as items are added to the stack, the stack pointer is

   309 decremented. This means that if the stack overflows, the stack pointer points

   310 into the guard area and causes a processor exception, with the result that

   311 the kernel panics the thread. </p> <fig id="GUID-C87444AA-A8DC-5A5C-B2E6-B15FA69B6CE1">

   312 <image href="GUID-DD0DA06D-4180-54F1-8807-A7BF31D6A1F1_d0e70450_href.png" placement="inline"/>

   313 </fig> <p>Return addresses are stored by pushing them on to the stack so at

   314 any point you can trace through the stack looking at the saved return addresses

   315 to see the chain of function calls up to the present function. </p> <p>The

   316 size of the user-side stack space has an indirect effect on the number of

   317 threads that a process can have. There are other factors involved, but this

   318 is an important one. The limit is a consequence of the fact that a process

   319 can have a maximum of 16 chunks. This means that if threads within a process

   320 can share a heap (allocated from a single chunk), then it is possible to have

   321 a maximum of 128 threads per process [2Mb/(8K + 8K)]. More threads may be

   322 possible if you allow only 4K of stack per thread. </p> <p>Apart from the

   323 kernel stack attached to each thread, the kernel also maintains stacks that

   324 are used during processing of interrupts, exceptions and certain CPU states.

   325 Interrupts and exceptions can occur at any time, with the system in any state,

   326 and it would be dangerous to allow them to use the current stack which may

   327 not even be valid or may overflow and panic the kernel. The kernel stacks

   328 are guaranteed to be large enough for all interrupt and exception processing. </p> </section>

   329 <section id="GUID-E3F102A4-D187-5BC9-BE97-9F8447A5DB45"><title>Virtual memory

   330 and run addresses</title> <p>Symbian platform devices have an MMU which is

   331 used to map the addresses seen by running code to real addresses of memory

   332 and I/O. The MMU in effect creates a virtual memory map, allowing scattered

   333 blocks of RAM to appear contiguous, or for a section of memory to appear at

   334 different addresses in different processes, or not at all. </p> <p>Symbian

   335 platform uses the MMU to provide memory protection between processes, to allow

   336 sharing of memory, efficient allocation of RAM and to make all processes “see”

   337 the same memory layout. Three different memory models are supported by Symbian

   338 platform on ARM CPUs: </p> <ul>

   339 <li id="GUID-456A3D12-E1E0-5289-B5EB-2E3A47F07684"><p>moving model: this is

   340 the model familiar from EKA1 where processes are moved to a run-address in

   341 low memory when executing and moved back to a home-address in high memory

   342 when not running. </p> </li>

   343 <li id="GUID-3A5BCC68-7BAC-58B8-9727-54A880A7CED3"><p>direct model: this is

   344 used when the CPU does not have an MMU, or is emulating a system without an

   345 MMU. Not normally used, but occasionally useful for development boards </p> </li>

   346 <li id="GUID-7CB07322-B33E-5723-975C-6D2442B924F9"><p>multiple model: only

   347 supported in ARM architecture V6 and above, each process has its own set of

   348 MMU tables. A context switch changes the current MMU table to the new thread’s

   349 table, instead of moving memory about in a single table as with moving model. </p> </li>

   350 </ul> <p><b>Fixed

   351 processes</b> </p> <p>For ARM architectures with a virtually-tagged cache,

   352 fixed processes avoid the need to flush the cache on context switches by keeping

   353 all the code and data at a fixed address. This implies that there can only

   354 ever be one instance of each fixed process because the data chunk address

   355 cannot be changed. </p> <p>Important servers such as the file server and window

   356 server are fixed. </p> <p>There is no limit to the number of fixed processes

   357 that can be supported. The kernel will attempt to use ARM domains for fixed

   358 process protection, but there are a limited number of domains so when they

   359 are exhausted normal MMU techniques will be used. Domains are slightly faster

   360 in a context switch but this is negligible compared to the real purpose of

   361 the fixed process in avoiding the cache flush. </p> </section>

   362 </conbody></concept>