[libcxx-dev] <atomic> for bare-metal development on ARM microcontrollers

[Yves Delley via libcxx-dev]

Dear libc++ developers,

I am experimenting with clang++ together with libc++ on ARM M4 
microcontrollers, with the intent to test the viability of the new C++20 
coroutines on them (using the -fcoroutines-ts switch of clang). I have 
had some moderate success, resulting in a usable toolchain based on the 
archetypical newlib C-library: 
https://github.com/burnpanck/docker-llvm-armeabi .

However, currently, I build libc++ without threading support, because 
I'm targeting bare-metal without RTOS. Unfortunately, that immediately 
disables `<atomic>`. This is a pity, because even if there is no 
fully-fledged threading available, bare-metal development has to deal 
with concurrency in the form of interrupts. Here, library support for 
`<atomic>` would be much appreciated.

Is there any particular reason why `<atomic>` needs threading support 
under all circumstances? I understand that a library implementation in 
absence of compiler intrinsics requires at least a "unique_lock". But on 
a microcontroller, one could just disable interrupts for the duration of 
the atomic operation, as there is no need for memory synchronisation. 
Would it make sense to try detaching atomics from threads to support 
vendor supplied atomics, similarly to `<__external_threading>`?

The alternative, trying implement threading support for that target 
(with working synchronisation primitives but no actual threads) seems a 
much heavier task. At least, it also pulls in the requirement for a 
monotonic clock.

I would love to hear your thoughts on the subject.

Thanks and best regards

Yves