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