Search the Forum for answers or post your questions to the
Quantum Leaps community
 |
 |
|
| Home | | | Products | | | Services | | | Downloads | | | Licensing | | | Developer Zone | | | Resources |
 |
| Overview | | | Discussion | | | Cookbook | | | Design Patterns | | | Bugs | | | Contributions | | | Credits |
Quantum Leaps Discussion Forum
Search the Forum for answers or post your questions to the |
||
| Return to Website | ||
 First |
 Prev |
 Reply |
 Forum |
Next  |
Last  |
| Viewing Page 1 of 1 (Total Posts: 3) |
| Author | Comment |
Balamurugan
Jan 15, 08 - 3:02 AM |
Query on Deferred events state pattern
Hello, I need some clarification on deferred events implementation on QP framework. The implementation of QP is such that, events can be deferred at any point and added to event queue,and can be recalled at later point of time. But consider the situation,number of events(say 10)are added in a single deferred queue and we have to recall a event which is not in the last but should be in the middle of the queue.And also it should not disturb the other queued events. The wise solution is one queue should be added for each deferring event.If no of events increases then this solution may not be correct. How to achieve this using QP implementation?or any modification required? Regards Bala |
Miro Samek
 Jan 15th, 2008 - 5:50 AM |
Re: Query on Deferred events state pattern
The event deferral mechanism of QF allows you to use as many deferred event queues as you need. Specifically, the QActive_defer()/QActive_recall() functions take the deferred event queue pointer as a parameter, so you control which event queue you defer to and recall from. Typically, you need a separate deferred event queue for each event signal. For example, you might defer event signals REQUEST_A to requestA event queue object, and signals REQUEST_B to requestB event queue object. With this design, you can both recall and defer REQUEST_B events independently from REQUEST_B events. This might be necessary, because your state machine might be ready be ready to recall REQUEST_A events, but not ready to recall REQUEST_B. In summary, the QF mechanism can handle an open-ended number of deferred event queues, so no modifications of the mechanism are required to cover your case. Finally, I'd like to make sure that you use the QActive_recall() method correctly. Even though QActive_recall() returns a pointer to the recalled event, you should not process it at the point of recalling. By the time QActive_recall() function returns, the event is already posted to the active object’s event queue using the last-in-first-out (LIFO) policy, which guarantees that the recalled event will be the very next to process. (If other events were allowed to overtake the recalled event, the state machine might transition to a state where the recalled event would no longer be convenient.) The state machine will then handle the event like any other request coming at the convenient time. This is the central point of the "Deferred Event" design pattern. --Miro |
|
Balamurugan
Jan 15th, 2008 - 8:05 PM |
Re: Query on Deferred events state pattern
Hello Miro, Thanks for your instant reply. Thanks a lot for introducing me the concept of state machine based programming approach. |
| First |
Prev |
Reply |
Forum |
Next |
Last |
bravenet.com| Privacy Statement | About Us | Contact Us | © 2004-2005 quantum Leaps. All rights reserved. |