atomic builtin

Asked by Jonathan Dumaresq on 2017-04-10

Hi,

Is it possible to use the atomic feature of c++11 with the latest version of the compiler ? I try with Version 6.2 and I have linker problem.

here the snipet:
void main(void)
{
 volatile std::atomic<uint64_t> a;
 a = 55ULL;
}

I got this linker error

6.2.1\bits/atomic_base.h:386: undefined reference to `__atomic_store_8'

Regards

Jonathan

Question information

Language:
English Edit question
Status:
Answered
For:
GNU ARM Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
2017-04-10
Last reply:
2017-04-11
Tejas Belagod (belagod-tejas) said : #1

That's a call to libatomic. libatomic is unsupported for baremetal toolchains.

Tejas Belagod (belagod-tejas) said : #2

Hi Jonathan,

What CPU are you targeting? If it's a Cortex-M that's expected because they do not have instructions for 64bit atomic operations. uint32_t would work on these devices and uint64_t would work on Cortex-A and Cortex-R devices.

Best regards.

Jonathan Dumaresq (jdumaresq) said : #4

Hi,

I use cortex-M4 devices. I know that uint64_t was unsupported. Thats why the atomic rely on atomic_store_8 to do something atomic. I have found a base libatomic on gcc wiki that help me to write the stub. I know this is very os dependant and need to be adjusted for each situation.

http://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c

At least I have been able to use it on M4.

I don't know if they exist other implementation of this library for M4 devices ? Something to base on developement.

Regards

Jonathan

David Brown (davidbrown) said : #5

I had a little look at that library, and I think it contains a critical flaw that makes it fail here. The implementation uses spinlocks to control access to atomics bigger than 32 bit. The idea is simple - get the lock, do the access, release the lock. And spinlocks are an efficient but risky way to do this on a system like Linux, but a terrible way for the typical embedded system. The problem is if one thread holds the long, and another higher priority thread gets the processor access and tries to get the lock - that higher priority thread will wait indefinitely for the lock. There is no scope for priority boosts.

A quick test of a couple of atomic accesses in gcc 6 for the ARM show very poor implementations - library calls for things that should be a couple of assembly instructions.

Can you help with this problem?

Provide an answer of your own, or ask Jonathan Dumaresq for more information if necessary.

To post a message you must log in.