joel.sherrill at oarcorp.com
Thu Apr 5 16:37:00 UTC 2007
Johan Zandin wrote:
> Johan Zandin wrote:
>>> Imagine for example the following, extremely simple software
>>> (which is very similar to the scenarios we have been running
>>> in the simulator the latest week):
>>> 1 low priority idle task doing nothing.
>>> 1 high priority active task doing this:
>>> while (true)
>>> Start hardware activity X.
>>> Wait for semaphore S.
>>> Do some other stuff for a long time without releasing the CPU.
>>> 1 ISR which
>>> a) Is executed whenever hardware activity X is completed.
>>> b) Just signals the semaphore S.
>>> If you are unlucky enough with the hardware timing, the ISR will
>>> _always_ occur just in the critical part of _Thread_Dispatch,
>>> when RTEMS is on its way to dispatch the idle task! In the long run,
>>> not even a 4 GB stack for the idle task will help you then...
> Joel Sherrill wrote:
>> But your CPU utilization is near 100%. The high priority task is
>> repeatedly consuming nearly all CPU time before the interrupt occurs.
>> There is just enough time to partially return to the IDLE thread.
> Confirmed. So let me make a more realistic (but still very simple
> example) to show that the current RTEMS behaviour can be a real problem:
> 1 low priority idle task doing nothing and never running.
> 1 medium priority task, using all "free" CPU time
> to do stuff without any particular deadline.
> (On your desktop, this could be stuff like SETI at home.
> But in realtime systems, it's more likely some kind
> of needed-but-not-urgent housekeeping activities, e.g.
> checking the RAM memory or collecting statistics.)
> 1 high priority active task doing this:
> while (true)
> Wait 10 seconds.
> for (i = 0; i < 1000; i++)
> Start hardware activity X.
> Wait for semaphore S.
> 1 ISR which
> a) Is executed whenever hardware activity X is completed.
> b) Just signals the semaphore S.
> With the same unlucky hardware timing as in my previous example,
> the medium priority task stack will be filled up during the for loop,
> unless it has a margin of at least 1000 times the size of the frame
> added when it is just "halfway" dispatched. (On SPARC, that would
> correspond to 376000 bytes of extra stack space, for that task alone.
> And this is a small example...)
Yes. If the time between the 1000 interrupts is insufficient for the
task to block and the lower priority task to pop the previous interrupt
The bigger question is what -- if anything -- can be done to minimize
in such a situation?
You really preempted the lower priority task and that required saving
You really switched to the higher priority task and left that subroutine
your lower priority stack so it could eventually return.
Would running _ISR_Dispatch with interrupts disabled until the final return
from interrupt instruction help or would it just make a nasty critical
One random thought... would it help if _Thread_Dispatch_disable_level were
left at 1 when the interrupted thread returns from the context switch on a
_Thread_Dispatch from an ISR_Dispatch until you returned to
_ISR_Dispatch and redisabled interrupts? I would have to think of the
correctness (not sure it would behave right) and the mechanics
involved to get that to happen but it should prevent scheduling out of
an ISR until
we were done. If not implemented right, it also might prevent
desirable interrupts that occurred during this sequence so you would have
to be extremely careful.
Said another way .. There might be a way to set things up so either
interrupts or dispatching
was off the entire path through an _ISR_Dispatch EXCEPT when you
context switched to the other task.
> Best regards
> /Johan Zandin
> Johan Zandin Software Engineer
> Saab Space AB Phone: +46-31-735 41 47
> SE-405 15 Gothenburg, Sweden Fax: +46-31-735 40 00
More information about the users