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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals