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

[wei.a.yang at gmail.com]

OK, I will submit the nop-stub funtions for other architectures ASAP.

在 2013-2-11，0:01，Gedare Bloom <gedare at rtems.org> 写道：

> I don't see how to get around the lack of correct atomic operations if
> we end up using atomic ops in the kernel. We will need to implement
> the atomic operations for every architecture in that case for
> correctness. For now can we provide a nop-stub version of the atomic
> operations so that we can continue with this work without blocking
> until every arch is supported?
> 
> On Sat, Feb 9, 2013 at 12:30 AM,  <wei.a.yang at gmail.com> wrote:
>> 
>> 在 2013-2-9，2:46，Gedare Bloom <gedare at rtems.org> 写道：
>> 
>>> On Fri, Feb 8, 2013 at 11:48 AM, Joel Sherrill
>>> <joel.sherrill at oarcorp.com> wrote:
>>>> 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.
>>> Still have to convert the atomic operations into something that would
>>> work if we want to use atomic operations throughout the kernel or
>>> export them to users.
>>> 
>>>> 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?
>>> Could we do something like this for a generic up load (store is similar)?
>>> 
>>> #define Atomic_##TYPE _CPU_Atomic_Load_##NAME(Atomic_##TYPE *p) { \
>>> ISR_Level level; \
>>> Atomic_##TYPE tmp; \
>>> ISR_Disable(level); \
>>> tmp = *p; \
>>> ISR_Enable(level); \
>>> return tmp;\
>>> }
>>> 
>> From the technical view this generic atomic function is suitable for the uniprocessor, but it will disable interrupts. So I am not sure whether it is maybe not safe for some situation.
>> 
>>>> --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
>>>> 
>>>> _______________________________________________
>>>> rtems-devel mailing list
>>>> rtems-devel at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-devel