On 2014-10-02 15:09, Daniel Gutson wrote:
On Thu, Oct 2, 2014 at 6:16 AM, Daniel Cederman <ceder...@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
ceder...@gaisler.com
www.Aeroflex.com/Gaisler
_______________________________________________
devel mailing list
devel@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
ceder...@gaisler.com
www.Aeroflex.com/Gaisler
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
