[rtems commit] tests: atomic support for RTEMS. Uniprocessor tests for atomic ops.

[Joel Sherrill]

On 2/8/2013 10:09 AM, wei.a.yang at gmail.com wrote:
> In the atomic.inl it has a comment 
>  " *
> + *  In the event that a CPU does not support a specific atomic function it has, the 
> + *  CPU dependent routine does nothing (but does exist).
> + */
> "
> If the architecture does not support atomic it should have a min stub to make compile ok.
>
> But I wonder whether there is a necessary to define a macro HAVE_ATOMIC like HAVE_SMP
HAVE_SMP is generated by autoconf. It would be preferable to either
have a stub or a CPU_HAS_ATOMIC_OPERATIONS define in cpu.h. This makes
the code self-contained with no dependencies on the build system.

A stub has one advantage -- code can compile. But my concern is that
by providing non-functional stubs, are we making a promise to the
end user that may not be met. Can safe portable versions be provided
for uniprocessor environments?

--joel
> 在 2013-2-8，9:36，Chris Johns <chrisj at rtems.org> 写道：
>
>> Gedare Bloom wrote:
>>> I suppose the question is whether we want to let code that includes
>>> the atomics compile for an unsupported CPU. I think we should define a
>>> minimal stub that allows the code to compile and assert(false) so that
>>> any user that actually tries it will get an obvious failure.
>> I suppose this comes down to the place conditional support for atomics is placed and their use in the kernel. If RTEMS only supported SMP systems all archs would need to provide them and asserts would work. As RTEMS does not it would mean every place an atomic is used a conditional define is needed (yuck) or the atomic call becomes a 'nop' on archs with no atomic instructions or when being built for a single cpu system where atomic locking is not needed.
>>
>>> An alternate solution would be to use automagic to prevent the
>>> spatomic* from being included.
>> No thanks.
>>
>>> Maybe if we had an experimental flag :)
>> :)
>>
>> Chris
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
> _______________________________________________
> 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