On Fri, Feb 21, 2025 at 5:28 PM JOHN MORRISON via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Tiago,
>
> You are right in a saying that thread ownership isn't a thing. There is only thread execution and that is why the compiler can't help here and there is no declarative solution. It is also true that a unique_ptr doesn't necessarily run in the thread in which it is created. The thread checking mechanism does anticipate that. It associates a thread id with a unique_ptr<T, notify_ptrs<T> > when the first ptr_to_unique is taken from it and a control block is allocated. That works out quite well. I have been wanting to share how this works:
>
> For thread A to pass a ptr_to_unique to thread B, thread A first has to create a ptr_to_unique to pass which causes a control block to be allocated stamped with thread A. Trying to use it from thread B will trigger an exception.
>
> When thread A moves or swaps a unique_ptr<T, notify_ptrs<T> > held object into thread B, the move or swap is carried out by thread A but all ptr_to_uniques that reference it are zeroed. It is virgin again and no longer associated with a control block. There won't be one to stamp until it is running in thread B and a ptr_to_unique is taken from. It will then create a control block stamped with thread B and all use from thread B will work as expected.
>
> I thinks its cool because it stops what you don't want to happen but doesn't impede what you do want to happen …... as far I have been able to anticipate. But its logic is circumstantial and doesn't have a solid foundation. It is a band aid just to stop you doing the wrong thing and there is something lame about that. That exception will only hit you once. After that you won't go there again.
>
> I believe you when you say that it will be rejected for that.
>
> Perhaps the correct way to look at it is to say that ptr_to_unique works with unique_ptr (declared with the notify_ptrs deleter), a unique_ptr can only have single thread visibility and we have always had to conform to this. So there you have clear domain of safe use where your use of unique_ptr will already be sitting and where the use cases can be found.
>
> If you want data to be safely visible to multiple threads then it must have shared ownership and you will be using shared_ptr/weak_ptr for that, not unique_ptr.
>
> So why complain that ptr_to_unique can't do threadsafe cross thread dereferencing when a unique_ptr is never put in that position and we already have shared_ptr/weak_ptr to do that. It is like complaining that a cat doesn't bark.

The issue I have with your thinking is that it requires the notion
that `unique_ptr` has "single thread visibility". That's not true. Or
at least, it's not the total truth.

`unique_ptr` cannot be shared across threads because it cannot be
*shared* across anything. It doesn't have "single thread visibility";
it has "single ownership". The latter implies that it only exists on
one thread, but that's merely a byproduct of unique ownership.

Similarly, while `shared_ptr` allows sharing across threads, that is
also a byproduct of permitting shared ownership. That is, if ownership
can be shared, then it should be able to be shared across threads.
Simialrly, if ownership is unique, then it cannot be shared across
threads.

Put simply: threading is immaterial. Ownership is unique or shared,
and if it's shared, then threads should not be excluded from the
sharing. Threads are first-class citizens of C++; they should not be
treated as special unless there is no other choice.

I contend that what you are trying to create is not an extension of
"unique ownership"; you are trying to create a form of "shared
ownership" where there is one object that controls destruction, but
other objects that can know if destruction has happened.

Those other objects may have weak ownership, but it is still a form of
ownership. Why? Because once they get a pointer to the object, that
object *must* continue to exist until that code is done with it.

What you want to do is make it so that this is guaranteed only so long
as those weak owners are in the same thread as the real owner. But
this is the first case where ownership is *specifically* identified
with threading. Note the above: `shared_ptr` allows sharing between
threads because it doesn't want to make a distinction between
different kinds of owners.

You are trying to make such a distinction. But you're not making it at
an API level. That is, there is no mechanism in the API that makes it
in any way difficult to transfer weak ownership to another thread,
even though this weak ownership cannot be shared with another thread.

`unique_ptr` has built-in restrictions that make it impossible within
the language to share ownership, as defined by the object. You cannot
copy it, and because it's not trivially copyable, there is no legal
C++ mechanism to copy it otherwise. You can pass pointers or
references around, but that doesn't imply ownership the way the object
defines that concept. The object is in a certain place with a certain
scope, and that scope defines the ownership of the object it
maintains.

Can you misuse a `unique_ptr`? Yes. You can get the pointer it manages
and store it in a new `unique_ptr` instance; now two objects uniquely
own it. But the API is doing as much as it possibly can (within the
C++ language) to prevent you from doing things like that.

And this is also why there is no `shared_within_thread_ptr`: because
there is no API mechanism that would prevent sharing across threads,
so its API would just be `shared_ptr`'s API.

Either it's uniquely owned or it's shared, including threads. This
middle ground you want where it's shared within a thread is not a
place the standard library ought to go unless there is some way to
actually put that into the API.

And yes, I argue that this is still shared ownership. It's a weak
relationship, but it's still shared ownership. At some point, the code
with a `ptr_to_unqiue` is going to have to get a pointer to the
object. And if it is valid, it must remain valid during that time.
That is a form of ownership.