Symbian OS nanothreads

.. as promised  🙂

So far we talked a lot about kernel threads, to be precise nanokernel threads, we need to say a few words about them.
Threads are basic units of execution of the nanokernel. They are represented as a collection of data that describes one of the points a program reached its execution. I am saying one of the points because kernel supports multi-threading, meaning that a program can execute multiple threads.

Basically any program, from structural point of view, can be stripped down into multiple threads. Many threads can be groupped into a process what do they have in common is a shared address space.This is indeed the definition of a process: an instance of a computer program, consisting of one or more threads, that is being sequentially executed by a computer system that has the ability to run several computer programs concurrently. (just taken from Wikipedia).

The differences between a program and a process are two: a program may consist in multiple processes and a process in disregard with a program is an active entity, is a program in execution, besides corresponding chunk of memory allocated it has also CPU time allocated.

Nanokernel threads always run in supervisor mode, they never run in user mode, so they need only one stack. In Symbian OS all the informations about a thread are kept in NThreadclass, which on its turn is derived from NThreadBase, whose definition is kept in nk_priv.h. Maybe it will be useful at a lter moment in time to go a little bit through those classes and to say few words about their members and methods, but for the moment this is not required.

Let’s just take a quick look over a  golden reference concerning Operating Systems a. In  Silberschatz and Galvin’s book: Operating Systems concepts it is given following example about the benefits that a multi-threading program may have:

In certain situations a single application may be required to perform several similar tasks. For example, a web server accepts client requests for web pages, images, sound, and so forth. A busy web server may have several (perhaps hundreds) of clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time. The amount of time that a client might have to wait for its request to be serviced could be enormous.

One solution is to have the server run as a single process that accepts requests. When the server receives a request, it creates a separate process to service that request. In fact, this process-creation method was in common use before threads became popular. Process creation is very heavyweight, as was shown in the previous chapter. If the new process will perform the same tasks as the existing process, why incur all that overhead? It is generally more efficient for one process that contains multiple threads to serve the same purpose. This approach would multithread the web-server process. The server would create a separate thread that would listen for client requests; when a request was made, rather than creating another process, it would create another thread to service the request.

So here you have extracted below the advantages of a multi-threading system:

responsivness– it is easier for a program to handle multiple actions, some of the actions may be blocked but this is not blocking the entire functionality of the program (in our case, of the process)

economy of resources – let’s see what is needed to maintain a process and a thread: each procss is generally represented in any operating system by a process control block.  This is a data structure which contains following informations: start pointer, process state, process ID, various registers (stack pointer, program counter .., CPU scheduling information (its priority), memory management information (where does it fit in memory, value of base and limit registers)). If you want to delegate a new task to another process you will have to create another PCB (process control block) which takes a lot of time (creating a new process will take tens of times more than creating a threas and a context switch in between two existing processes is alos several times slower than a context switch in between threads) and lot of space (memory) All the threads within one single process share the same address space – that’s the big deal with threads

encourages processors’ concurency – for systems having more than one processor, different threads can be assigned for execution to different processors or within the same processor an illusion of parallelismn can be creating by the use of pipelining.

But … let’s come back to our nanothreads, one thing is important to say about them: they live and die !

Nanokernel creates threads via Create function from NThread class.  Nanokernel cannot allocate memory therefore anyone creating a nanothread must first allocate a stack for it. It can live NThread::Kill() in one of the following states : Ready, Suspend, WaitFastSemaphore,  WaitDfc, Sleep, Blocked, Death and “other” .You can kill a thread via NThread::Kill(), but … attention ! this is not encouraged,  it is nicely to stop them, this will allow a thread to perform its exit routine. An exiting thread will perform its exit handler, in case if exists, this will manage to delete its thread control block.


One Response to Symbian OS nanothreads

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: