Libatomic support

[Daniel Cederman]

On 2014-10-02 15:09, Daniel Gutson 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.

libatomic provides support for doing atomic operations on data types 
larger than the ones supported by hardware. It does this by using locks, 
so for lock-free programming it is of no real use.

A simple example:

#include <stdatomic.h>

_Atomic struct Big {
   int a;
   int b;
   int c;
   int d;
   int e;
} global;

int main()
{
   struct Big local;

   local = global;

   return 0;
}

The assignment to local should be done atomically. The compiler 
transforms the assignment to a call to __atomic_load, which is 
implemented in libatomic. There the memory range that global is 
occupying will be locked and then memcpy:ed to local.

The strange thing is that gcc allows members of the _Atomic struct to be 
read without taking locks, which seems wrong. clang does not allow this.

/Daniel C



> 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 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