1

Asynchronous Services

2

Background and need for Asynchronous Services

• Typically, Symbian OS applications are event based: 1. The application is constructed and initialised.2. The application starts waiting for events from the user or from the OS

services3. When an event occurs, the application handles the event and starts waiting for

a new event.• Events can be generated by e.g:

– The user • Key events• Events generated by the UI (e.g. menu)

– Service providers• Timers • File server• Network servers

• The UI events are handled by AppUi but we need event handlers for other services.

3

Synchronous vs. asynchronous services

• In Symbian OS, most services are provided through servers, which can be accessed through the functions of R-classes (those are for example RFile or REtel).

• R-classes provide synchronous and asynchronous service functions:1. If your application calls synchronous function, the code (the application’s

thread) stops until the service is completed and the function returns.

2. If your application calls asynchronous function, the function returns immediately, while the request itself is processed in the background.

• Synchronous services should be quick operations e.g. requesting a system state information which can be responded immediately.

4

Asynchronous services

• Many services require a lot of time to complete which makes synchronous functions unusable (thread blocked). Examples:– An application opens a large document.– An application waits for an picture to be processed.

• Instead, we use asynchronous service functions, where a service function returns immediately and the service is processed in the background.

• Since the application thread is not blocked, application can process other tasks like responding to user input or updating the display.

• When the request is complete, the program receives a notification, which will then be handled by e.g:– Threads (in many systems)– Active objects (in typical Symbian OS application)

5

Asynchronous services and multi-threaded applications

• In many systems, applications are implemented as multi-threaded processes, where asynchronous services are handled as follows: • For each new asynchronous task a new execution thread is spawned to handle it.

• A scheduler makes decisions on which thread is executed.

• A thread polls the service provider to see if the request is completed.

• Once a service is completed the corresponding thread makes the required actions.

• Disadvantages of multi-threaded practice:– Multiple threads lead to increasing number of context switches increasing

system overhead.

– Programmer need to take care of synchronization, deadlock and other process management issues making programming more complex.

6

Asynchronous services and Active Objects

• A typical Symbian OS application is implemented as a single thread process which can handle multiple asynchronous services.

• The technique is cooperative multitasking where there is a wait loop going through the outstanding task requests.

• Once the wait loop finds a completed task, it calls the event handler code of the corresponding handler object.

• This is done by using active object framework where each asynchronous service request has an active object waiting the request to be completed.

• In Symbian OS:– The wait loop is implemented as an Active Scheduler.

– Handler objects are implemented as Active Objects.

7

Active Object Classes

• Active Object: derived from CActive class. Encapsulates:

– asynchronous request (e.g. to server or to service provider)

– application’s handler for the completed request

– plus functionality for cancellation of the request!

• Active Scheduler: derived from CActiveScheduler class.

– schedules Active Objects non-pre-emptively within an application (AOs have priorities but cannot pre-empt each other)

– encapsulates waitloop processing of events

– one per thread

– When we create new thread and if it handles active objects then we need CActiveScheduler. If we don’t handle any asynchronous service then we don’t need it.

– Multiple active objects can be added with different priority in the active objects.

8

The Active Scheduler

• The active scheduler is implemented by CActiveScheduler.

• The active scheduler maintains a list ordered by priority, of all active objects of the application.

• The active scheduler implements the wait loop for an application thread. The wait loop goes through the iStatus boolean flags of active objects of iActive flag set on.

• If the iStatus is other than KRequestPending (meaning that the request is completed), the Active Scheduler calls the RunL method of the active object.

• Following UML diagram shows that a process can have 1 or more thread and each thread can have 0 or 1 active scheduler. Each active scheduler can have 0 or more active objects.

9

Active object priorities• If more than one active object gets the service completed in the

same time, the Active Scheduler chooses the one with the highest priority. The priorities are:

• You can set the priority in constructor.

EPriorityIdle A low priority, useful for active objects representing background processing

EPriorityLow A priority higher than EPriorityIdle but lower than EPriorityStandard

EPriorityStandard Most active objects will have this priority.

EPriorityUserInput A priority higher than EPriorityStandard; useful for active objects handling user input

EPriorityHigh A priority higher than EPriorityUserInput

10

Active Objects• Active objects are classes which request asynchronous services

and once completed, handle the requests. They contain:– A data member representing the status of the request (iStatus)

– A handle on the asynchronous service provider (R-class object).

– Connection to the service provider (established during the construction through the R-class object).

– The user-defined function to issue the asynchronous request.

– The handler function to be called by the Active Scheduler when the request completes (RunL).

– The function to cancel an outstanding request (Cancel).

• An application can contain 0-n Active Objects.

• Active Objects are implemented by deriving CActive class.

11

Definition of CActive class

class CActive : public CBase

{

public:

~CActive();

void Cancel();

TBool IsActive() const;

protected:

CActive(TInt aPriority);

void SetActive();

virtual void DoCancel() =0;

virtual void RunL() =0;

public:

TRequestStatus iStatus;

private:

TBool iActive;

};

12

CActive methods• SetActive() sets the Active Object active by setting iActive ETrue.

• IsActive() returns the state of iActive.

• Cancel() is a public function to cancel the service request.

• DoCancel() method implements the service request cancellation. This user-defined method is typically called by Cancel() method.

• RunL() method is called by the Active Scheduler when the request completes. Here is the implementation of event handling.

• RunError() you can override to handle leaves from RunL(). The default implementation causes the Active Scheduler to panic.

Methods for derived classes (real active objects):

• Base class contains no actual function for issuing an asynchronous request. You must define one. Typical methods are IssueRequest() or Start().

13

CActive member variables

• TRequestStatus iStatus contains the state of request. The initial state is KRequestPending. This variable is:– Modified by service provider once the request is completed

– Monitored by the Active Scheduler in the wait loop

• TBool iActive tells whether the Active Object is active.

14

Dynamic behaviour of Active Object mechanism

Original diagram from Symbian?

15

The life-cycle of an Active Object

1. An application creates and installs the Active Scheduler. This is done automatically (in UI applications).

2. The Active Object is constructed and added to the Active Scheduler. – Remember to call CActiveScheduler::Add( this ) in the constructor.

3. The Active Object is set active by calling its IssueRequest() method in which the request is sent and iStatus is sent to the service provider for modification.– Remember to call SetActive() in the method after sending the request.

Now Active Object has requested the service and is active. The Active Scheduler is looping the Active Object and monitoring its iStatus.

16

4. The service provider completes the request and sets iStatus from KRequestPending to a new value.

5. The Active Scheduler recognizes the new status and calls the RunL() method of the Active Object.

6. The response is handled in RunL() and after that the Start() method can be called again (if applicable).

The life-cycle of an Active Object

17

Example: Using Asynchronous Timer• Header file:

class CMyTimerAo : public CActive{public:

CMyTimerAo();~CMyTimerAo();void Start(); void Cancel();void RunL();

private:void DoCancel();

private: // An integer representing a timing period

TInt iPeriod;

// A hanlde to timing servicesRTimer iTimer;

};

18

• Implementation:CMyTimerAo::CMyTimerAo() : CActive( EPriorityStandard ){

iPeriod = 5000000;// IMPORTANT: Add AO to the schedulerCActiveScheduler::Add( this );// Create a timer for this threadiTimer.CreateLocal();// Start active objectStart();

}CMyTimerAo::~CMyTimerAo(){

Cancel();}void CMyTimerAo::Start(){

// Register to get asynchronous timing event (request service)if( !IsActive() ) // Check if we have made any request previously, only one active request at a time{

iTimer.After( iStatus, iPeriod ); // Service provider specifies this method, completion is notified by iStatus SetActive();

}}

19

void CMyTimerAo::Cancel(){

DoCancel();}

void CMyTimerAo::DoCancel(){

// Cancel an outstanding request from timer.iTimer.Cancel();

}void CMyTimerAo::RunL() // When timer is expired then RunL() is called{

// Timing service completed. Add your code here.// Start again if applicableStart();

}

20

Life cycle of Timer ExampleConsole

2. Create AO, issue request& add to Active Scheduler

CMyTimer

5. Start Active Scheduler

Active Scheduler

3. Issues request functionand call SetActive()

Timer

4. set object’s iStatus to KRequestPending

7. request completed: reset object’s iStatus to KErrNone

6. WaitForAnyRequest()

1. Create and Install Active Scheduler

8. call AO’s RunL()9. RunL() function re-issues request or stops active scheduler

10.Cleanup and terminate

Key

Procedural flow:

Control transferred:

(asynchronous)

Wait for the period

21

Summary

• Active Objects used instead of multi-threading: non pre-emptive scheduling within a single-threaded process

• In most cases, synchronization is easier than using thread

• Context switch between thread is not necessary when we are using active objects

• Active Objects avoid the use of mutexes for data sharing

• One CActiveScheduler per thread

• CActive-derived concrete classes must implement RunL() and DoCancel()

• Active Objects used throughout Symbian OS: CServer derived from CActive

• Note: real-time/time critical tasks should be implemented using threads and processes

• CONE provides two active objects to handle events from the window server: one for user input events and one for redraw events.