rtems_semaphore_obtain

[Johan Zandin]

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...)


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