On 2/18/2014 10:20 AM, Gedare Bloom wrote: > On Tue, Feb 18, 2014 at 10:19 AM, Joel Sherrill > <joel.sherr...@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.sherr...@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@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@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@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
