| Subject: |
|
Re: Quantum Leaps Newsletter, April 08 |
| Name: |
|
Miro Samek |
| Date Posted: |
|
Apr 17, 08 - 5:52 PM |
| Email: |
|
miro@quantum-leaps.com |
| Website: |
|
http://www.quantum-leaps.com |
| Message: |
|
Lawrence,
Thank you for the insightful comment, as usual.
The main reason for locking the scheduler during event multicasting in QP v3 was to avoid premature recycling of an event. Consider a scenario in which an event is published by a low-priorty AO to a higher-priority AO. If the scheduler is active, the higher-priority AO immediately preempts the low-priority AO and executes the RTC step. After the RTC step, the high-priority AO will recycle the event, while the event still needs to be posted to other subscribers.
The problem just described has been avoided in QP v4 by incrementing the reference count of the event inside QF::publish() right before multicasting the evnt. This prevents premature recycling of the event just described, so, scheduler locking is not really necessary to achive correct event recycling.
However, you are right that QP v4 will behave possibly differently from QP v3 when executed under a *preemptive kernel" and oublishing occurs from low-priority AOs. I would not call it "reprioritization" of events, becuase events don't have priorities. But I understand that you mean potential reordering of events. Again, for other readers of this forum, the scenario could be as follows. We have three active objects A, B, and C, of priorities low, medium, and high, respectively. Active object B of medim priority publishes an event EVT_1 to A and C. Because in QP v4 the scheduelr is *not* locked, the high-priority AO C immediately preempts the medium-pririty AO B just after the first event posting. Now, assume that C posts an event EVT_2 to A in its RTC step. After this, B resumes and continues multicasting by posting event EVT_1 to A. After all this, the event queue of A has two events (EVT_2, EVT_1) in the reversed order.
In contrast, in QP v3, the high-priority C will only run after the whole multicasting completes, so the queue of AO A will have (EVT_1, EVT_2) in the shown order.
I guess that the general feeling is that QP v3 is more correct by handling multicasting atomically. On the other hand, it requries locking the scheduler for potentially up to 63 event postings, which increases direclty the task level response.
QP v4 does not lock the scheduler, so has a much better task-level response. The ordering of events in QP v4 is maybe less intuitive at a first glance, but is consistent with the model that event publishing is exactly like multiple event postings starting from the highest-priority subscriber.
As they say, every sufficently sophisticated bug is undistinguishible from a feature. I'm not sure if this difference between QP v3 and QP v4 is a bug or a feature. But thank you for bringing this up and giving me an opportunity to explain the difference.
Miro |
|
|
|
|
|
|
Reply
Forum
bravenet.com