Gsoc2012: Atomic operation for RTEMS

[yangwei weiyang]

Hi all,

Last week there are two issues to be solved.
1. Whether the atomic specific date type is needed. After some
discussion i found there is no need to define those date types and
rtems basic date types are enough. So i have replace all those date
types with rtems basic date types.
2. The atomic API definitions should be made static inline. After some
comparison with the solutions i move all the atomic definitions in
atomic_manager.c originally to atomic.inl. And then atomic.h include
the atomic.inl.

The repository is in the github on which i have create a separate
branch "atomic". https://github.com/WeiY/rtems/commits/atomic.
Comments are welcome.

2012/6/6  <wei.a.yang at gmail.com>:
>
>
> 在 2012-6-6，11:45，Ralf Corsepius <ralf.corsepius at rtems.org> 写道：
>
>> On 06/06/2012 03:46 AM, Chris Johns wrote:
>>> On 6/06/12 12:33 AM, Sebastian Huber wrote:
>>>>
>>>> No, the "atomic_cpu_generic.h" should provide the type definitions for
>>>> reasonable architectures. It is good to have architecture specific types
>>>> like Atomic_Int, but I think on most architectures it will be "typedef
>>>> Atomic_Int int". For all architectures with straight forward type
>>>> definitions we can use "atomic_cpu_generic.h".
>>>>
>>>
>>> This is a good idea.
>>
>> What would this be useful for?
>>
>> I don't see any reasons to have typedefs for "Atomic types" on ordinal types or POSIX types, except of "API stylishness".
> Yeah, Ralf. You are right. I select the "Atomic type" that mostly because of the API stylishness. In fact using the basic date types which are type defined based on date types supported by program language is also ok, such as uint_32.
>>
>> More generally speaking, the only technical reason to have typedefs on ordinal types or POSIX types would be to cover "exotic" architectures, whose toolchains do not implement all of these types.
>>
>> In practice, nowadays, such architectures/toolchains are pretty rare to find.
>>
>> Ralf
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel



-- 
Wei Yang
Best Regards

wei.a.yang at gmail.com