C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::shared_ptr resurrect

From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Date: Tue, 12 Dec 2023 10:08:25 +0100
pon., 11 gru 2023 o 23:23 Andrey Semashev via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On 12/11/23 22:42, Marcin Jaczewski via Std-Proposals wrote:
> > pon., 11 gru 2023 o 18:26 Thiago Macieira via Std-Proposals
> > <std-proposals_at_[hidden]> napisał(a):
> >>
> >> On Monday, 11 December 2023 08:45:31 PST Valentin Palade wrote:
> >>> Doing a local copy as Jonathan suggests, will make no difference, with
> >>> threads running concurrently, we can still have use_count() return anything
> >>> between 1 and 5.
> >>>
> >>> Or am I missing something?
> >>
> >> No. It can be between 1 and 5.
> >>
> >> But if it's 1, then you have the only copy and there is no other thread seeing
> >> this object. The number can't change unless the current thread changes it.
> >
> > But all threads can return 5 too. As check is done before decrement
> > every one can observe the state before it.
> > And this means no thread can get 1 and acquire the last instance.
> > We need to guarantee that one thread will be the least instance.
>
> Yes, but the same can happen with the proposed resurrect() method as well.
>

No, as it first decreases counter then checks for zero, this means it
never sees 5,
only 4 at least. As this is an atomic operation every one will see a
unique value.
With enough checks like this, someone needs to see 0 at some point.
Only exception would be that unrelated threads have access to one of
the pointers
and copy it before decrement.

> If this is a concern then a better solution is to use a custom deleter
> that will pass the object to the producer instead of deleting it.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2023-12-12 09:08:35