rtems_semaphore_obtain

[Joel Sherrill]

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 
high priority
task to block and the lower priority task to pop the previous interrupt 
frame off
the stack.

The bigger question is what -- if anything -- can be done to minimize 
the damage
in such a situation? 

You really preempted the lower priority task and that required saving 
some state.
You really switched to the higher priority task and left that subroutine 
call on
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 
section?

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 
scheduling on
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.

--joel
> 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
> -----------------------------------------------------------
>