Author Topic: Scheduler behavior on interrupt event  (Read 7470 times)

Offline rnardone

  • Newbie
  • *
  • Posts: 6
    • View Profile
Scheduler behavior on interrupt event
« on: November 09, 2008, 04:21:28 PM »

Assume we have a uTasker system with 10 tasks running, the order of the tasks in the main task table is simply #1 through #10.  The scheduler has allowed task #2 to run, and an asynchronous hardware interrupt arrives.  The interrupt service routine sends an interrupt event message to task #8. 

What happens next?  What does the scheduler do when task #2 is done?  Does it go on to task #3 or does it jump down to task #8, that has an interrupt event message waiting? 

I'm trying to make sure I understand the basic scheduler behavior here with respect to interrupt latencies.

Thanks in advance,

   Rick

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Scheduler behavior on interrupt event
« Reply #1 on: November 09, 2008, 11:10:23 PM »
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#msg235
http://www.utasker.com/forum/index.php?topic=160.0

Regards

Mark