You could have an API along the lines of:
```

bool accessed = ptr.try_access([] (T& ref) { ref.function1();
ref.function2(); });

```

But I am not sure if we are getting any advantage over shared_ptr. Is there
a reference implementation that can show how it works and how it solves the
problem better/being more lightweight than shared_ptr?


// Robin

On Mon, Feb 24, 2025, 03:11 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday, 23 February 2025 19:40:38 Brasilia Standard Time Henry Miller
> via
> Std-Proposals wrote:
> > What this gives us that operator->() doesn't is direct knowledge when the
> > function is done and thus an obvious place to release the lock.
>
> That's hardly a correct assumption. No one would write:
>
> mutex.lock();
> ptr->function1();
> mutex.unlock();
> mutex.lock();
> ptr->function2();
> mutex.unlock();
>
> Aside from the extra code this is generating and the possibly strain this
> is
> putting on the cache traffic, the fact that you unlocked between function1
> and
> function2 implies the state may have completely changed. There may be
> cases
> where this is an acceptable behaviour, but in the general case it won't
> be,
> and that's why I said assuming the end of the expression is the correct
> place
> to unlock.
>
> In the majority of cases, I expect a lock to need to be held across
> multiple
> invocations, so one must either get a locked proxy object that prevents
> the
> state from changing underneath the object, or must explicitly lock
> themselves.
> If the latter, an automatic lock by the class would be either superfluous
> or
> would be a trigger for deadlocks.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>