change log for rtems (2011-08-22)

[Joel Sherrill]

On 09/26/2012 07:21 AM, Sebastian Huber wrote:
> On 08/22/2011 09:10 PM, rtems-vc at rtems.org wrote:
>> 2011-08-22	Jennifer Averett<Jennifer.Averett at OARcorp.com>
>>
>> 	PR 1876
>> 	* score/Makefile.am, score/include/rtems/score/isr.h, score/src/isr.c,
>> 	score/src/smp.c, score/src/smplock.c, score/src/threaddispatch.c,
>> 	score/src/threaddispatchdisablelevel.c: Add smp isr support.
>> 	* score/src/isrsmp.c: New file.
>>
> [...]
>> diff -u rtems/cpukit/score/src/threaddispatch.c:1.25 rtems/cpukit/score/src/threaddispatch.c:1.26
>> --- rtems/cpukit/score/src/threaddispatch.c:1.25	Thu May 26 13:07:07 2011
>> +++ rtems/cpukit/score/src/threaddispatch.c	Mon Aug 22 13:26:08 2011
>> @@ -169,9 +169,10 @@
>>      }
>>
>>    post_switch:
>> -  _Thread_Dispatch_set_disable_level( 0 );
>>
>>      _ISR_Enable( level );
>>
>> +  _Thread_Unnest_dispatch();
>> +
>>      _API_extensions_Run_postswitch();
>>    }
> [...]
>
> This change and previous changes in the file threaddispatch.c are very bad.  In
> fact they destroy the real-time properties of RTEMS completely.
>
> Consider the following scenario.  We have three tasks L (lowest priority), M
> (middle priority), and H (highest priority).  Now let a thread dispatch from M
> to L happen.  An interrupt occurs in _Thread_Dispatch() here:
>
> void _Thread_Dispatch( void )
> {
>     [...]
>
> post_switch:
>
>     _ISR_Enable( level );
>
>     <-- INTERRUPT
>     <-- AFTER INTERRUPT
>
>     _Thread_Unnest_dispatch();
>
>     _API_extensions_Run_postswitch();
> }
>
> The interrupt event makes task H ready.  The interrupt code will see
> _Thread_Dispatch_disable_level>  0 and thus doesn't perform a
> _Thread_Dispatch().  Now we return to position "AFTER INTERRUPT".  This means
> task L executes now although task H is ready!  Task H will execute once someone
> calls _Thread_Dispatch().
Yep. :(
> We should restore the previous behaviour at least for non-SMP configurations.
> I am not sure how to deal with SMP here, but the current solution turns RTEMS
> into a non-real time system.
>
I am going to have to think on this to remember the full rationale that
drove this.

I do remember that before this change ISR disable/enable and thread 
dispatching
disable/enable did not nest properly.  It was:

   disable dispatch
     disable ISR
      ...
     enable dispatch
   enable ISR

With the SMP implementation of disable/enable dispatch, I recall this 
resulted in
a deadlock.

This needs to be thought through carefully. If you want to ifdef this 
for now
based on SMP to get the old behaviour back on non-SMP, commit it. For SMP,
we will have to think more on this.

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985