Thread vs Active Object
This article compares and contrasts using Symbian's Active Objects and threads for asynchronous service handling, and explains why Active Objects are preferred in Symbian C++ code.
Symbian is a heavily asynchronous operating system. Virtually all system services are provided through servers, which operate in their own process for high reliability.
Service provider APIs typically have asynchronous and synchronous versions of their functions available to their client applications, but to avoid blocking the application's user interface you would usually use the asynchronous version. Most time-consuming operations are therefore made as a request to some asynchronous service provider, such as the file system. The service request function returns immediately, while the request itself is processed in the background. This means that the program needs to receive some notification in the future when the request is complete, and in the meantime it needs to be able to get on with other tasks like responding to user input or updating the display.
A common solution to this problem is to spawn a new execution thread to handle each asynchronous task, making the request and awaiting completion—often by polling the request provider to see if the request has completed yet. Although this approach is possible in Symbian a more efficient approach on Symbian is to use Active Objects. These provide a lightweight co-operative multitasking framework to handle asynchronous services. Please refer to Fundamentals of Symbian C++/Active Objects for complete understanding of Active Objects with examples.
Difference Between Active Object and Thread
Active objects multitask cooperatively within a thread and, once handling an event,an active object cannot be pre-empted by the active scheduler in which it runs. On the other hand, threads in Symbian OS are scheduled pre-emptively by the kernel.
As a consequence, data shared by threads must be protected with access synchronization primitives such as mutexes or semaphores, as opposed to active objects where no synchronization is needed.
When to Use Thread
There are rare occasions where the use of threads may be necessary, say to perform a task which cannot be split into short-running increments. By implementing it in a separate thread, it can run asynchronously without impacting an application’s response to user interface events
Advantages of Active Objects over threads
- They run in the same thread, which incurs a lower overhead than a thread context switch between multiple threads.
- No data synchronization is required.
- On Symbian OS, the use of active objects for event-handling multitasking is ideal because they are designed for efficiency.
- Threads increases memory consumption as each thread has its own stack allocated.
- Context switch between threads is slower than switching between active objects in the active scheduler loop.
Simple Example for Thread
// Name of the new thread
// Creates a thread belonging to the current process
// and opens this handle to that thread.
TInt res = iThread.Create( KThreadName, ThreadEntryPoint, KDefaultStackSize,
// Makes the thread eligible for execution. After a thread is created,
// it is put into a suspended state; the thread is not eligible to
// run until Resume() is called.
// Control passes to this function when the thread is first resumed,
// i.e. when the thread is initially scheduled to run
// It just changes the value of the variable.
TInt CThreadExampleAppUi::ThreadEntryPoint(TAny* param)
TInt* para = static_cast<TInt *>(param);
*para = 1;
ThreadEntryPoint must be a static function, otherwise a compilation error is generated.
Symbian OS is optimized for single-threaded applications, and the use of active objects is preferred instead of multi-threading. As a rule of thumb, you should always use single-threading in Symbian OS programs, unless you know exactly why not to do so.