Date: Mon, 17 Feb 2025 11:55:29 +0000
I don’t think it needs to compromise on single-ownership.
I can see 2 solutions for this:
1. Give up on thread safety. The owning pointer only takes the responsibility to notify any weak pointer constructed from it. It works, just not in a multithreaded setup.
2. Locking the destructor of an owning pointer if a weak pointer acquires some sort of lock. Can lead to a dead lock. Would definitely be the most dangerous of the bunch.
In either case it requires an intermediate object to connect between the owning pointer and the weak pointer such that communication can take place, you can’t do it with a regular unique_ptr.
It’s not entirely unworkable.
You could write this in a library and experiment with it.
It could work in theory, but given the compromises, it’s already rare that you get to use weak_ptr, it could be hard to find a set of conditions where you would use it but also couldn’t just use a shared_ptr. When you delete that owned object, do you actually need it to be deleted at that exact moment? If the answer is yes, then you probably have a use case.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of JOHN MORRISON via Std-Proposals
Sent: Monday, February 17, 2025 12:34 PM
To: std-proposals_at_[hidden]
Cc: JOHN MORRISON <inglesflamenco_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
Simon Cooke wrote: If we look at the intended usage, the pattern that gets us there is an
object that owns a private shared_ptr, but only hands out weak_ptrs from
its API surface.
Hi Simon,
This idea has been mentioned and discussed a few times. A special type of single ownership pointer that can be shared just for the duration of weak_ptr dereferences – a kind of unique_ptr with elastic destruction . The idea is that it would provide threadsafe references to singly owned objects from multiple threads and the required destruction delay will be so short that it won't be a problem.
To work it would require three new smart pointers:
* A new single ownership pointer that wraps a shared_ptr but presents a unique_ptr public interface.
* A new type of weak_ptr that can reference it and can only convert to the new type of shared_ptr mentioned below.
* A new type of shared_ptr that can only be constructed from the new type of weak_ptr and that cannot be copied, shared or converted to a normal shared_ptr.
I think that could be done with a bit of work. It sounds cool because it would allow what was never before possible and that we have always carefully avoided, singly owned objects being safely visible to multiple threads.
But is the idea fundamentally sound? Its magical bucking of the normal rules sounds too good to be true and that is because it isn't true. It still compromises single ownership. Even a short destruction delay can disrupt carefully crafted destruction sequences. It also overlooks the fact that we often use background threads to carry out lengthy tasks so we could be holding our supposedly singly owned object alive for quite some time. Lifetime elasticity is unwelcome in single ownership because it is all about being tight and timely.
This idea is an attempt to magically buck the reality that singly owned items should never be visible to multiple threads. This is a reality that we have always accepted and worked with and trying to pretend that it is otherwise is always going to be some kind of fragile illusion.
The proposed ptr_to_unique is designed to fully respect single ownership without compromising it in any way. It assumes that you will not be exposing your singly held object to multiple threads and you won't because you never did because it is not something you can ever do safely – you need shared ownership for that. If you use threads you will know that. If you don't use threads then it doesn't matter that you don't.
The following post has a lengthy rebuttal of the concerns about lack of thread safety with the proposed ptr_to_unique and I am trying to draw attention to it.
https://lists.isocpp.org/std-proposals/2025/02/12468.php
I can see 2 solutions for this:
1. Give up on thread safety. The owning pointer only takes the responsibility to notify any weak pointer constructed from it. It works, just not in a multithreaded setup.
2. Locking the destructor of an owning pointer if a weak pointer acquires some sort of lock. Can lead to a dead lock. Would definitely be the most dangerous of the bunch.
In either case it requires an intermediate object to connect between the owning pointer and the weak pointer such that communication can take place, you can’t do it with a regular unique_ptr.
It’s not entirely unworkable.
You could write this in a library and experiment with it.
It could work in theory, but given the compromises, it’s already rare that you get to use weak_ptr, it could be hard to find a set of conditions where you would use it but also couldn’t just use a shared_ptr. When you delete that owned object, do you actually need it to be deleted at that exact moment? If the answer is yes, then you probably have a use case.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of JOHN MORRISON via Std-Proposals
Sent: Monday, February 17, 2025 12:34 PM
To: std-proposals_at_[hidden]
Cc: JOHN MORRISON <inglesflamenco_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
Simon Cooke wrote: If we look at the intended usage, the pattern that gets us there is an
object that owns a private shared_ptr, but only hands out weak_ptrs from
its API surface.
Hi Simon,
This idea has been mentioned and discussed a few times. A special type of single ownership pointer that can be shared just for the duration of weak_ptr dereferences – a kind of unique_ptr with elastic destruction . The idea is that it would provide threadsafe references to singly owned objects from multiple threads and the required destruction delay will be so short that it won't be a problem.
To work it would require three new smart pointers:
* A new single ownership pointer that wraps a shared_ptr but presents a unique_ptr public interface.
* A new type of weak_ptr that can reference it and can only convert to the new type of shared_ptr mentioned below.
* A new type of shared_ptr that can only be constructed from the new type of weak_ptr and that cannot be copied, shared or converted to a normal shared_ptr.
I think that could be done with a bit of work. It sounds cool because it would allow what was never before possible and that we have always carefully avoided, singly owned objects being safely visible to multiple threads.
But is the idea fundamentally sound? Its magical bucking of the normal rules sounds too good to be true and that is because it isn't true. It still compromises single ownership. Even a short destruction delay can disrupt carefully crafted destruction sequences. It also overlooks the fact that we often use background threads to carry out lengthy tasks so we could be holding our supposedly singly owned object alive for quite some time. Lifetime elasticity is unwelcome in single ownership because it is all about being tight and timely.
This idea is an attempt to magically buck the reality that singly owned items should never be visible to multiple threads. This is a reality that we have always accepted and worked with and trying to pretend that it is otherwise is always going to be some kind of fragile illusion.
The proposed ptr_to_unique is designed to fully respect single ownership without compromising it in any way. It assumes that you will not be exposing your singly held object to multiple threads and you won't because you never did because it is not something you can ever do safely – you need shared ownership for that. If you use threads you will know that. If you don't use threads then it doesn't matter that you don't.
The following post has a lengthy rebuttal of the concerns about lack of thread safety with the proposed ptr_to_unique and I am trying to draw attention to it.
https://lists.isocpp.org/std-proposals/2025/02/12468.php
Received on 2025-02-17 11:55:36