Can we get a shared_ptr with non thread-safe reference counting?

[Viktor Kirilov]

Is there a chance to have a non thread-safe shared_ptr in the standard?

I was thinking either as a new template or maybe the current shared_ptr should have a template parameter if it's ref counting should be atomic.

This shouldn't be hard to implement - its a simpler case for the current shared_ptr.

There is interest in such a thing - http://stackoverflow.com/questions/6593770/creating-a-non-thread-safe-shared-ptr

Andrei Alexandrescu talked at the cppcon how to implement such a pointer yourself ( https://www.youtube.com/watch?v=Qq_WaiwzOtI ) but I think the standard should provide one.

Currently the only publicly available solution seems to be building boost with a flag/define to disable thread-safe reference counting (according to that StackOverflow question).

I posted this first in [std-discussion] but maybe it belongs here.

[Nadav Har'El]

Another project where non-thread-safe shared_ptr was desired - and implemented - is the Seastar project (http://www.seastar-project.org/). Seastar is an open-source C++14 library for building high-performance server applications.

For optimum performance on many-core machines, Seastar applications use the share-nothing approach (different cores work on different data), so shared pointers are never shared between threads, and thus do not need thread-safety. The traditional thread-safe reference counting implementation, using the x86 atomic increment/decrement instructions, significantly slows down the use of shared pointers - and even worse (as far as the Seastar project is concerned), ruins its scalability as the number of cores becomes large (especially on multi-socket setups).

So you can find in Seastar's thread-unsafe implementation of std::shared_ptr in it's source code (this implementation is Apache-licensed, so may be reused by almost anyone):

https://github.com/cloudius-systems/seastar/blob/master/core/shared_ptr.hh

Seastar actually implemented two variants - one is shared_ptr, compatible with the traditional std::shared_ptr (without the thread safety). The second one is lw_shared_ptr, an even lighter variant which uses smaller pointers (just one machine pointer) and smaller overhead added to the shared object - but doesn't permit polymorphism. In many situations, this lightweight variant is enough, and provides even better performance.

By the way, I'd like to add that in theory, it might be possible to have our cake and eat it too, i.e., have a reference-counter which is *both* thread safe and scalable in number of cores. One of the relevant research papers I've read in the past about how to do this is "SNZI: Scalable NonZero Indicators". Using this or similar algorithm, one might implement the existing std::shared_ptr in a scalable way, without giving up on the thread-safety guarantee. But I'm guessing that while SNZI-like methods will indeed be more scalable, they might not be any faster on a machine with only a few cores. These sort of techniques will become very important as the number of cores on machines continue to increase, and even when we do need thread-safety, it never needs to involve all cores.

Nadav Har'El.

[Viktor Kirilov]

I couldn't find weak_ptr functionality within the Seastar project along with the shared_ptr.

I'm more interested in having this in the standard.

Has anyone ever proposed it?

What chances will it have getting into the standard if it is proposed?

[Nadav Har'El]

On Sun, Apr 19, 2015 at 2:03 PM, Viktor Kirilov <vik.k...@gmail.com> wrote:

I couldn't find weak_ptr functionality within the Seastar project along with the shared_ptr.

I think this wasn't needed there, so it was never implemented, but there's no real reason not to add it.

I'm more interested in having this in the standard.

In order to suggest why something should be in a standard, it is usually good to have evidence that this idea actually works, and is useful in practice. I suggested that Seastar is an evidence why your idea is indeed useful (as well as being implementation you can try today).
 

Has anyone ever proposed it?

What chances will it have getting into the standard if it is proposed?

I don't know :-) I'm a newbie on this list. Let's wait for more knowledgeable people to respond.

[Ville Voutilainen]

On 19 April 2015 at 14:03, Viktor Kirilov <vik.k...@gmail.com> wrote:
> I'm more interested in having this in the standard.
> Has anyone ever proposed it?

Not that I recall. The decision to make shared_ptr thread-safe was
well-considered
and deliberate, but there was no prejudice against a non-thread-safe
one should a
need for such thing arise.

> What chances will it have getting into the standard if it is proposed?

Given a good proposal with decent motivation (which the outline of the Seastar
project and its needs provides to certain extent), it stands a decent
chance. I would not be surprised
by various sorts of conservative opposition. It's hard to predict
which way it will go.

Personally I find it an idea worth proposing.