But I have no experience with non-x86 platforms and don't know where
boost::shared_ptr is still used and which of the platform-specific
implementations are still needed. (Neither do I know on which platforms the
atomic and the sync intrinsics actually work, as opposed to just compile and
then fail to link.)
Any information along these lines is welcome. If you know of a platform
where boost::shared_ptr is still used, but which supports none of the
"modern" ways to implement atomic ops, please let me know. If you would like
some of the plaform-specific files to be retained, please let me know.
Thanks in advance.
This brings back memories. It's about a decade since I was writing
ARM code for Boost.Atomic and/or shared_ptr.
At the time I suggested that shared_ptr should use Boost.Atomic, so that
we could do all the architecture-specific code once. That didn't
least because it was a while before Boost.Atomic was actually reviewed and
I think the summary is that on gcc + ARM platforms you should use the gcc
atomic builtins, or libstdc++ std::atomic (which invokes those
it exists. They do the right thing with minimal work. No need for any
Before ARMv6 the only atomic instruction was an atomic swap. There are
still ARMv4t systems shipping; I'm coding for one right now. But they are
probably all microcontrollers, and it would be surprising to find anyone
using shared_ptr on them. There is still support in gcc; you can use
std::atomic if you implement __atomic_* (which might involve disabling
interrupts, for example). I've just tried std::shared_ptr, which compiles
and seems to use a non-atomic reference count.
ARMv5 embedded systems running Linux are also still shipping. On Linux,
the gcc builtins have kernel support which makes them quite efficient. Linux
distributions still support ARMv5 (Debian dropped support for ARMv4 last
year) so all sorts of exotic code is regularly being built for ARMv5 on
their build farms; you don't want to break this. None of these systems
ARMv6 added ldrex/strex, and atomics can be implemented without OS
support using these in a loop. Again the gcc atomic builtins do the right
thing. This was mostly unchanged in ARMv8 and ARMv8 though at some point
byte and halfword and possible 8-byte atomics have been added. This
represents the vast majority of ARM systems. On iOS, I'd guess that
clang must provide the same atomic builtins as gcc which will do the
right thing but I've not checked that.
ARMv8.2 added a true set of atomic instructions. I believe the new AWS
ARM instances support these so they could be important to some users.
Presumably the gcc builtins would support them but only if a sufficiently-new
gcc knew it was targetting only that architecture variant. That raises the
question of executables that attempt to determine what atomic implementation
to use at run time....