1 / 21

Asynchronous Services

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

jeneva
Download Presentation

Asynchronous Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Asynchronous Services

  2. Typically, Symbian OS applications are event based: The application is constructed and initialised. The application starts waiting for events from the user or from the OS services 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. Background and need for Asynchronous Services

  3. 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: If your application calls synchronous function, the code (the application’s thread) stops until the service is completed and the function returns. 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. Synchronous vs. asynchronous services

  4. 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) Asynchronous services

  5. 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. Asynchronous services and multi-threaded applications

  6. 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. Asynchronous services and Active Objects

  7. 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. Active Object Classes

  8. 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. The Active Scheduler

  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.

  10. 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. Active Objects

  11. 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; }; Definition of CActive class

  12. 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(). CActive methods

  13. 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. CActive member variables

  14. Dynamic behaviour of Active Object mechanism Original diagram from Symbian?

  15. An application creates and installs the Active Scheduler. This is done automatically (in UI applications). The Active Object is constructed and added to the Active Scheduler. Remember to call CActiveScheduler::Add( this ) in the constructor. 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. The life-cycle of an Active Object

  16. The service provider completes the request and sets iStatus from KRequestPending to a new value. The Active Scheduler recognizes the new status and calls the RunL() method of the Active Object. 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. 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 services RTimer iTimer; }; Example: Using Asynchronous Timer

  18. Implementation: CMyTimerAo::CMyTimerAo() : CActive( EPriorityStandard ) { iPeriod = 5000000; // IMPORTANT: Add AO to the scheduler CActiveScheduler::Add( this ); // Create a timer for this thread iTimer.CreateLocal(); // Start active object Start(); } 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 applicable Start(); }

  20. Life cycle of Timer Example Console 1. Create and Install Active Scheduler Timer CMyTimer 4. set object’s iStatus to KRequestPending 2. Create AO, issue request & add to Active Scheduler 3. Issues request function and call SetActive() Wait for the period 5. Start Active Scheduler Active Scheduler 7. request completed: reset object’s iStatus to KErrNone 6. WaitForAnyRequest() (asynchronous) Key Procedural flow: Control transferred: 9. RunL() function re-issues request or stops active scheduler 8. call AO’s RunL() 10.Cleanup and terminate

  21. 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. Summary

More Related