| Subject: |
|
Re: Initial Transition QP-Nano |
| Name: |
|
Miro Samek |
| Date Posted: |
|
Jul 9, 08 - 3:14 PM |
| Email: |
|
miro@quantum-leaps.com |
| Website: |
|
http://www.quantum-leaps.com |
| Message: |
|
Actually, in QP-nano 4.x, active objects are initialized in the order of priority, starting from priority 1 (see QF_run() in qfn.c and QF_run in qkn.c). So, by the time the highest-priority AO is initialized, all other AOs in the system have their priorities assigned and are ready to accept events.
However, in the full-version QP (QP/C and QP/C++), the order of starting active objects is left to the application designer. So, generally speaking there is no guarantee that a peer active object must be ready to accept events sent from the top-most initial transition of another active object.
The only universal guarantee in all versions of QP (QP/C, QP/C++, and QP-nano) is that an AO can safely post an event to self from the top-most initial transition.
I would recommend not to post/publish events to other active objects during the initialization transient (from the top-most initial transitions). The only exception could be posting to self, which is sometimes useful.
For example, MicroC/OS-II requires starting the time tick interrupt only after starting multitasking. Top-most initial transitions are therefore too early to start a system clock tick. Posting an event to self solves the problem, because such event can be processed only after the task is scheduled, that is after multitasking has started.
Miro |
|
Replies:
|
|
|
|
|
Reply
Forum
bravenet.com