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

karel pavlata k.pavlata@gmail.com
Mon Feb 19 10:58:00 GMT 2018


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

Why is _S_atomic not used? 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?

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

regards
karel



More information about the Libstdc++ mailing list