Libatomic support

[Daniel Gutson]

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.

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