Libatomic support

[Joel Sherrill]

On October 2, 2014 8:09:33 AM CDT, Daniel Gutson <daniel.gutson at tallertechnologies.com> wrote:
>On Thu, Oct 2, 2014 at 6:16 AM, Daniel Cederman <cederman at gaisler.com>
>wrote:
>>> I would not put too much time into this.  Who needs this stuff?
>>
>> Thanks for the comment. I thought it would be a quick fix to add
>support,
>> but looking at the code that gcc generates for _Atomic struct's I do
>not
>> really trust it to be correct. And on embedded platforms it is
>probably
>> better to get an undefined reference error and make a custom solution
>than
>> to add locks indirectly. So I will put this on hold.
>
>is libatomic the implementation of C++11's std::atomic?
>If so, it is more and more used in the "lock-free programming" trend.
>We *might* be interested in this C++11 feature to be available in
>RTEMS.
>Could you please let me know whether this is currently working
>suboptimally (i.e. using POSIX) or needs some work to be available?
>I'm not familiar with _Atomic but I could if this needs work.

My concern is that it should be there to have proper C++ 11 support. It is reasonable to assume that GCC C++ libraries can begin to use the underlying atomic support in implementing language libraries. I don't expect much explicit use of C++ 11 atomics soon directly by applications but by various support libraries. 

So improving it, questioning it, etc is important. It may be awesome on high end CPUs because it was conceived for them and we have to work to help improve it on the ones our community tends to use.

>Thanks!
>
>   Daniel.
>
>>
>>
>> On 2014-10-02 07:50, Sebastian Huber wrote:
>>>
>>> On 01/10/14 16:20, Daniel Cederman wrote:
>>>>
>>>> I'm looking at GCC's libatomic, which provides software emulation
>of
>>>> atomic
>>>> operations that are not supported by hardware. It does this by
>using a
>>>> compare-and-swap loop, or, failing that, using locks. At the moment
>it
>>>> is not
>>>> selected for compilation for RTEMS since it requires operating
>system (or
>>>> architecture) support for the locks. It needs support for two types
>of
>>>> lock/unlock operations. Here is a cut-and-paste from the
>libatomic_i.h
>>>> file in
>>>> libatomic:
>>>>
>>>>  >/* Locking for a "small" operation.  In the bare-metal single
>processor
>>>>  >   cases this could be implemented by disabling interrupts.  Thus
>>>> the extra
>>>>  >   word passed between the two functions, saving the interrupt
>level.
>>>>  >   It is assumed that the object being locked does not cross the
>>>> locking
>>>>  >   granularity.
>>>>  >
>>>>  >   Not actually declared here so that they can be defined static
>inline
>>>>  >   in a target-specfic <host-config.h>.
>>>>  >
>>>>  >UWORD protect_start (void *ptr);
>>>>  >void protect_end (void *ptr, UWORD);
>>>>  >*/
>>>>  >
>>>>  >/* Locking for a "large' operation.  This should always be some
>sort of
>>>>  >   test-and-set operation, as we assume that the interrupt
>latency
>>>> would
>>>>  >   be unreasonably large.  */
>>>>  >void libat_lock_n (void *ptr, size_t n);
>>>>  >void libat_unlock_n (void *ptr, size_t n);
>>>
>>>
>>> Yes, libatomic is for targets lacking proper hardware atomic
>>> operations.  So protect_start/end() should use
>>> rtems_interrupt_disable/enable().  For libat_lock_n/unlock_n() you
>can
>>> simply use the allocator lock for example.
>>>
>>> I would not put too much time into this.  Who needs this stuff?
>>>
>>
>> --
>> Daniel Cederman
>> Software Engineer
>> Aeroflex Gaisler AB
>> Aeroflex Microelectronic Solutions – HiRel
>> Kungsgatan 12
>> SE-411 19 Gothenburg, Sweden
>> Phone: +46 31 7758665
>> cederman at gaisler.com
>> www.Aeroflex.com/Gaisler
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
>-- 
>
>Daniel F. Gutson
>Chief Engineering Officer, SPD
>
>
>San Lorenzo 47, 3rd Floor, Office 5
>
>Córdoba, Argentina
>
>
>Phone: +54 351 4217888 / +54 351 4218211
>
>Skype: dgutson
>_______________________________________________
>devel mailing list
>devel at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel