atomic builtin

Asked by Jonathan Dumaresq


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'



Question information

English Edit question
GNU Arm Embedded Toolchain Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Tejas Belagod (belagod-tejas) said :

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

Revision history for this message
Tejas Belagod (belagod-tejas) said :
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said :

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.

Revision history for this message
Jonathan Dumaresq (jdumaresq) said :


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.

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.



Revision history for this message
David Brown (davidbrown) said :

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.