Hi Rick
The task table is always checked from top to bottom. This means that if an interrupt event has set task 8 to the run state as task 2 was running it will allow tasks 3,4,5,6,7 to run before it gets to task 8. The only prioritising is the ordering of the tasks in the table, however asynchronous event can occur anywhere so this doesn't means that task 1 has priority in this case since the scheduler could already be low in the list and so these will have first chance to run.
In the case of two tasks sending messaged to each other the situation is a little different since the task table position is known and so it would be possible to be sure that the receiving task always is the next to run (if it were positioned one down from the task sending to it - and waking it).
The worst case is always the time it takes for all 'other' tasks actually being run before the 'interrupted' task can work.
But remember that the system is more a state-event machine so it is quite unusual that more that one task is actually required to run at any time. If you activate the low power task you will find that even a quiet busy (state driven) system usually spends a large amount of time sleeping.
To control really critical stuff an interrupt call back is of course the way to do - it does the most critical work in the IRQ itself and then can use an interrupt event to do less critical work, like clean up work, 'off-line'. In the majority of cases it is found that quite a small amount of code usually needs to be performed in the IRQ itself (like saving some instantaneous values) and so the overall effect is generally still fast and efficient. The main goal here is also for simplicity. Pre-emptive operation has advantages in some circumstances but can also lead to unnecessary complications (and real project failures) in some circumstances where it has added unnecessary design risks.
The minimum latency in a pre-emptive system also will probably always be higher than a simple IRQ callback because it still has to do quite a lot of extra work to decide whether this IRQ is to be allowed to be processed at the moment or not...See also the following for some background:
http://www.utasker.com/forum/index.php?topic=59.msg235#msg235http://www.utasker.com/forum/index.php?topic=160.0Regards
Mark