Relevance of platfrom-specific shared_ptr implementations

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Relevance of platfrom-specific shared_ptr implementations

Boost - Dev mailing list
Greetings,

shared_ptr has a number of platform-specific implementations for its control
block, specifically the atomic reference count manipulation:

https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/detail/sp_counted_base.hpp

Those have been accumulated over the years and I'd like to clean them up,
remove the unused ones and fold as many of them as possible into a few
generic implementations using either std::atomic, GCC atomic intrinsics
(https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html)
or GCC/intel sync intrinsics
(https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html).

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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Relevance of platfrom-specific shared_ptr implementations

Boost - Dev mailing list
On 2020-05-31 17:18, Peter Dimov via Boost wrote:

> Those have been accumulated over the years and I'd like to clean them
> up, remove the unused ones and fold as many of them as possible into a
> few generic implementations using either std::atomic, GCC atomic
> intrinsics
> (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html)
> or GCC/intel sync intrinsics
> (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html).

How about a fall-back to Boost.Atomic?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Relevance of platfrom-specific shared_ptr implementations

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 31 May 2020 at 10:18, Peter Dimov via Boost <[hidden email]>
wrote:

> ... and fold as many of them as possible into a few **generic
> implementations** using ... GCC atomic intrinsics ... or GCC/intel sync
> intrinsics ...
>

Isn't this intrinsically flawed (highlight added)?

degski
--
@systemdeg
https://www.instapaper.com <http://instapaper.com>
"We value your privacy, click here!" Sod off! - degski

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Relevance of platfrom-specific shared_ptr implementations

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi Peter,

Peter Dimov wrote:

> shared_ptr has a number of platform-specific implementations for its control
> block, specifically the atomic reference count manipulation:
>
> https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/detail/sp_counted_base.hpp
>
> Those have been accumulated over the years and I'd like to clean them up,
> remove the unused ones and fold as many of them as possible into a few
> generic implementations using either std::atomic, GCC atomic intrinsics
> (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html)
> or GCC/intel sync intrinsics
> (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html).
>
> 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.)

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
happen, not
least because it was a while before Boost.Atomic was actually reviewed and
included.

I think the summary is that on gcc + ARM platforms you should use the gcc
atomic builtins, or libstdc++ std::atomic (which invokes those
builtins) if
it exists.  They do the right thing with minimal work.  No need for any
assembler.

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
are multiprocessor.

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


Regards, Phil.





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost