Uniprocessor Tests in SMP Configuration

[Joel Sherrill]

On 2/18/2014 10:20 AM, Gedare Bloom wrote:
> On Tue, Feb 18, 2014 at 10:19 AM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>> git
>> On 2/18/2014 1:12 AM, Sebastian Huber wrote:
>>> Hello Joel,
>>>
>>> On 2014-02-17 18:08, Joel Sherrill wrote:
>>>> Hi
>>>>
>>>> Has anyone reviewed the results yet?
>>> I executed the tests during development of the SMP priority scheduler.  All
>>> tests using unimplemented features fail.
>> And these are expected fails but is there a list of expected fails? The
>> impact of
>> those on coverage evaluated?
>>
>> I know our testing framework is poor and in the process of being improved
>> but this is important information.
>>>> With at least no-preempt and ISR disable level not honored
>>>> in the thread mode when SMP is enabled, I would assume
>>>> multiple tests are expected to break.
>>>>
>>> I collected unsupported features in SMP mode here:
>>>
>>> http://git.rtems.org/rtems/tree/testsuites/smptests/smpunsupported01/init.c
>>>
>>> What do you mean with "ISR disable level not honored in the thread mode when
>>> SMP is enabled"?
>>>
>> I misremembered the SMP conditionals in taskmode.c. Only no-preempt is
>> disabled.
>>
>> FWIW It may be better to not build task variables than to just return an
>> error. That is an entire class of capability that is not supported in
>> SMP. The tests for that would fail to link and could then just be
>> disabled from building.
>>
> I'd rather leave the tests as failing than to disable them. Eventually
> they should work if task variables get fixed?
Task variables are fundamentally and conceptually broken for SMP systems.

They are based on the assumption that one thread is running at a time
and there
is one memory image.  The contents of select locations in that one
memory image
can be context switched with the thread. With SMP, there are multiple
threads
running at a time and still only one memory image.

The one value in memory can only be correct for one of the threads.
>> Disable preemption is more subtle. The tests of rtems_task_mode()
>> need addressing. But other tests simply will not work. The impact on
>> coverage is unknown.
>>
>> Each feature not supported in SMP needs careful evaluation.
>>
> And analysis whether the feature will be supported in the future or if
> it is uni-processor only.
This can be made to work but the assumption that you made when writing a
thread
that is non-preemptible is violated. You disable preemption so you are
the only thread
executing for a block of code. It is a cheap critical section.

With a uniprocessor system, this results in a safe critical section. But
again, with multiple
cores, there are always multiple threads running at the same time and
the assumption
underlying the no-preempt is violated.

If no preempt is used to implement a run-to-completion tasking pattern,
then that is
likely OK. But it is more often used as cheap exclusive access to the
single CPU.

One underlying assumption is that if it isn't safe in SMP, then we need
to find a way to
"break" applications in an explicit as possible way. This encourages
application developers
to fix the issues before they find subtle bugs on target.

My intention is to write these issues up in the (new) SMP chapter in the
Users Guide
once Jennifer submits the guts of it with the new APIs.

Help is appreciated in adding content on broken design patterns, SMP
design patterns,
guidance, etc.
> -Gedare
>
>> --
>> 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
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel

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