shared_ptr's reference counter thread safety on ARM Cortex-M

[Jonathan Wakely]

On 19 February 2018 at 10:58, karel pavlata wrote:
> As per
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html
> libstdc++ does not guarantee thread safety with gcc built with
> --enable-threads=single, which is a case for all baremetal toolchains for
> ARM (Cortex-M) I've come across (which makes sense).
> When I examined  the dependencies for shared_ptr's reference counter it
> came down to __default_lock_policy being set to _S_single in concurrence.h
> which propagates to class _Sp_counted_base in shared_ptr_base.h. Also is
> _GLIBCXX_ATOMIC_BUILTINS not being set even when __atomic_fetch_add is
> available on the target platform and compiles into a pair of LDREX/STREX
> instructions which could be used to implement _S_atomic lock policy

I don't know - is it definitely not set?

> Why is _S_atomic not used?

Because --enable-threads=single means the library can assume there
will never be more than one thread, so why use atomic operations?

> Is there a way to build/configure gcc/libstdc++
> and/or the application to get thread safe shared_ptr on this (bare-metal
> ARM) platform?

Yes, don't use --enable-threads=single if you want to use multiple threads.

> If I understand it correctly there's technically nothing that should
> prevent it.