Process, Thread, Stack and Memory Attributes

Process and thread priorities

Internally the scheduler always deals with nanokernel threads, NThread objects, and their associated priority between 0 (lowest) and 63 (highest). In general, a thread with a higher priority that is ready to run will always run in preference to threads with a lower priority. The only exception is where a higher priority thread waits on a nanokernel fast mutex held by a lower priority thread. In this case, the higher priority thread will yield to the lower priority thread holding the mutex.

A Symbian platform thread, a DThread object, has an embedded NThread, which enables it to be scheduled by the nanokernel.

There are two ways of setting a priority for Symbian platform thread:

• using the two-level priority scheme

• using an absolute priority.

The two level priority scheme

In this scheme, a Symbian platform thread priority is relative to the priority of its owning process. By default, Symbian platform threads inherit the priority of their owning process when they are created. This priority can be raised or lowered relative to the process priority - this just sets the thread’s priority to the process priority plus or minus a specified priority weighting. If the priority of the process is changed, the priority of its threads will change relative to other threads in the system but will remain the same relative to each other.

The default priority of a process is EPriorityForgeround, which is an absolute priority of 350. Threads by default are created with relative priority EPriorityNormal which sets them to the same priority as the owning process. The window server lowers the priority of background UI processes to EPriorityBackground (250).

The NULL thread, also known as the idle thread, runs at priority 0, and means that it will only run when there are no other threads ready to run.

Symbian platform thread priorities map onto NThread priorities in the range 1 to 31 as shown in the table below.

where:

• the process priority values are defined by the internal Symbian platform enum TProcPriority, defined in ...\e32\include\kernel\kern_priv.h. The symbols in the table correspond to the symbols in the enum.

• the thread priority values are defined by the internal Symbian platform enum TThrdPriority, defined in ...\e32\include\kernel\kern_priv.h. The symbols in the table correspond to the symbols in the enum.

Absolute priority scheme

It is possible to set an absolute priority that is not relative to the process priority; it is not affected by changes in the process priority.

Thread state summary

This is a brief summary about nanokernel thread states and Symbian platform thread states.

Nanokernel thread states

The state of a nanokernel thread is referred to as the NState (or N-state). This is to disambiguate it from any other state, such as the state of a Symbian platform thread (referred to as the MState or M-state).

The states of a nanokernel thread are defined by the values of the NThreadBase::NThreadState enumeration.

Symbian platform thread states

The state of a Symbian platform thread is referred to as the MState (or M_state). This is in addition to the nanokernel N-state, and tracks threads waiting on Symbian platform synchronization objects. The DThread class representing a Symbian platform thread is internal to Symbian, but the following table defines its possible states. The values in the left-hand column are the enumerators of the internal enumeration DThread::TThreadState.

Thread and process exit information summary

User threads and processes have “exit information”. When a thread or process terminates the reason for the termination is found in the exit information. For example, a panic will store the panic category and reason in the exit information. Exit information has three parts: the exit type, exit reason and exit category.

Exit type is defined by the TExitType enum.

When a thread or process is created, its exit type is set to 3. An exit type of 3 indicates that the thread is still active, though not necessarily running. If the thread terminates for any reason, then the exit type is changed to reflect the cause of the exit.

Once the thread or process has exited, the exit reason and exit type fields will contain useful information. The contents depends on the type of exit.

Note that if the main thread in a process exits, then the process will exit with the same exit information as the thread.

Exit category: Terminate

if RThread::Terminate() or RProcess::Terminate() is called, then the exit category is Terminate, and the exit reason is the value of the aReason argument passed to these functions.

Exit category: Kill

If RThread::Kill() or RProcess::Kill() is called, then the exit category is Kill, and the exit reason is the value of the aReason argument passed to these functions.

Exit category: panic

If a thread panics, then the exit category is panic, and the exit reason is the panic number. For example a USER-19 panic would give the following exit information:

exit type = 2
exit category = “USER”
exit reason = 19

Critical threads and processes

Marking a thread or process as “system critical” means that it is an integral and essential part of the system, for example, the file server. In effect the thread or process is being declared necessary for correct functioning of the device. If a system critical thread exits or panics then the device will reboot; during development it will enter the debug monitor. A thread can be set as process critical, which means that if it panics the process will be panicked.

Kernel calls and thread context

When a user thread makes a call into any kernel code, the kernel code continues to run in the context of the user thread. This applies to device driver code.

The stack is swapped to a kernel-side stack and the permissions of the thread are increased to kernel privilege, but otherwise the user thread is still running. Each thread has a small kernel stack used to handle kernel calls – it would be dangerous to continue using the normal thread stack in case it overflows. Some calls are handled in this state, others – typically device drivers – will post a message to a kernel side thread to carry out the request.

Stacks

When a process is created, a chunk is allocated to hold the process executable's .data section (initialised data) and .bss section (zero filled data). Sufficient space (default 2Mb) is also reserved as user-side stack space for threads that run in that process.

By default, each thread is allocated 8k of user-side stack space. A guard of 8k is also allocated.

The stack area follows the .data and .bss sections, and each thread's user side stack follows. On ARM processors the stack is descending, so that as items are added to the stack, the stack pointer is decremented. This means that if the stack overflows, the stack pointer points into the guard area and causes a processor exception, with the result that the kernel panics the thread.

Return addresses are stored by pushing them on to the stack so at any point you can trace through the stack looking at the saved return addresses to see the chain of function calls up to the present function.

The size of the user-side stack space has an indirect effect on the number of threads that a process can have. There are other factors involved, but this is an important one. The limit is a consequence of the fact that a process can have a maximum of 16 chunks. This means that if threads within a process can share a heap (allocated from a single chunk), then it is possible to have a maximum of 128 threads per process [2Mb/(8K + 8K)]. More threads may be possible if you allow only 4K of stack per thread.

Apart from the kernel stack attached to each thread, the kernel also maintains stacks that are used during processing of interrupts, exceptions and certain CPU states. Interrupts and exceptions can occur at any time, with the system in any state, and it would be dangerous to allow them to use the current stack which may not even be valid or may overflow and panic the kernel. The kernel stacks are guaranteed to be large enough for all interrupt and exception processing.

Virtual memory and run addresses

Symbian platform devices have an MMU which is used to map the addresses seen by running code to real addresses of memory and I/O. The MMU in effect creates a virtual memory map, allowing scattered blocks of RAM to appear contiguous, or for a section of memory to appear at different addresses in different processes, or not at all.

Symbian platform uses the MMU to provide memory protection between processes, to allow sharing of memory, efficient allocation of RAM and to make all processes “see” the same memory layout. Three different memory models are supported by Symbian platform on ARM CPUs:

• moving model: this is the model familiar from EKA1 where processes are moved to a run-address in low memory when executing and moved back to a home-address in high memory when not running.

• direct model: this is used when the CPU does not have an MMU, or is emulating a system without an MMU. Not normally used, but occasionally useful for development boards

• multiple model: only supported in ARM architecture V6 and above, each process has its own set of MMU tables. A context switch changes the current MMU table to the new thread’s table, instead of moving memory about in a single table as with moving model.

Fixed processes

For ARM architectures with a virtually-tagged cache, fixed processes avoid the need to flush the cache on context switches by keeping all the code and data at a fixed address. This implies that there can only ever be one instance of each fixed process because the data chunk address cannot be changed.

Important servers such as the file server and window server are fixed.

There is no limit to the number of fixed processes that can be supported. The kernel will attempt to use ARM domains for fixed process protection, but there are a limited number of domains so when they are exhausted normal MMU techniques will be used. Domains are slightly faster in a context switch but this is negligible compared to the real purpose of the fixed process in avoiding the cache flush.