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

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

[karel pavlata]

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

Re: 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.

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

[Oleg Endo]

On Mon, 2018-02-19 at 15:07 +0000, Jonathan Wakely wrote:
> 
> > 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.
> 

Even though on such systems there might not be real threads, atomic
operations can still be useful, e.g. when sharing variables between the
"main thread" and interrupt handlers (adhoc preemptive threads so to
say).

Probably the easiest way around this issue is to pretend all
GCC/libstdc++ configury stuff that the system does support threads.
 Although it might open some cans of worms.  Another alternative is to 
hack-n-patch the toolchain source until it fits during the toolchain
build process.

BTW there is one related open issue that comes to mind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579


Cheers,
Oleg

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

[Jonathan Wakely]

On 19 February 2018 at 15:37, Oleg Endo wrote:
> Even though on such systems there might not be real threads, atomic
> operations can still be useful, e.g. when sharing variables between the
> "main thread" and interrupt handlers (adhoc preemptive threads so to
> say).

It would be fairly simple to add a new mode that means libstdc++
should use atomic ops, but not provide <thread>, <mutex> etc.

Somebody who cares about it just needs to do the work.

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

[karel pavlata]

Dňa pondelok 19. februára 2018 Jonathan Wakely napísal(a):

> On 19 February 2018 at 15:37, Oleg Endo wrote:
> > Even though on such systems there might not be real threads, atomic
> > operations can still be useful, e.g. when sharing variables between the
> > "main thread" and interrupt handlers (adhoc preemptive threads so to
> > say).
>
> It would be fairly simple to add a new mode that means libstdc++
> should use atomic ops, but not provide <thread>, <mutex> etc.
>
> Somebody who cares about it just needs to do the work.
>

This systems can (and usually do) run a lightweight non-posix RTOS so it
would be usefull. I'm not familiar with gcc's internals but will try to
look into that. If anybody can provide hints and/or caveats they're welcome.

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

[Jonathan Wakely]

On 19 February 2018 at 19:33, karel pavlata wrote:
>
>
> Dňa pondelok 19. februára 2018 Jonathan Wakely napísal(a):
>
>> On 19 February 2018 at 15:37, Oleg Endo wrote:
>> > Even though on such systems there might not be real threads, atomic
>> > operations can still be useful, e.g. when sharing variables between the
>> > "main thread" and interrupt handlers (adhoc preemptive threads so to
>> > say).
>>
>> It would be fairly simple to add a new mode that means libstdc++
>> should use atomic ops, but not provide <thread>, <mutex> etc.
>>
>> Somebody who cares about it just needs to do the work.
>
>
> This systems can (and usually do) run a lightweight non-posix RTOS so it
> would be usefull. I'm not familiar with gcc's internals but will try to look
> into that. If anybody can provide hints and/or caveats they're welcome.

I think the simplest approach would be to add a new --enable-xxx
option to libstdc++, which would be done by adding a new macro to
libstdc++-v3/acinclude.m4 and then using it in
libstdc++-v3./configure.ac

That should define a new preprocessor macro which overrides the
selection of __default_lock_policy in
lisbtdc++-v3/include/ext/concurrence.h and the behaviour of
__exchange_and_add_dispatch and __atomic_add_dispatch in
libstdc++-v3/include/ext/atomicity.h so that they don't only depend on
#ifdef __GTHREADS (which is not defined for --enable-thread=single).