change log for rtems (2011-08-22)
joel.sherrill at OARcorp.com
Wed Sep 26 13:42:04 UTC 2012
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 @@
>> - _Thread_Dispatch_set_disable_level( 0 );
>> _ISR_Enable( level );
>> + _Thread_Unnest_dispatch();
> 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 )
> _ISR_Enable( level );
> <-- INTERRUPT
> <-- AFTER INTERRUPT
> 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().
> 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
I do remember that before this change ISR disable/enable and thread
disable/enable did not nest properly. It was:
With the SMP implementation of disable/enable dispatch, I recall this
This needs to be thought through carefully. If you want to ifdef this
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
More information about the devel