shared_ptr's reference counter thread safety on ARM Cortex-M
Jonathan Wakely
jwakely.gcc@gmail.com
Tue Feb 20 20:05:00 GMT 2018
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).
More information about the Libstdc++
mailing list