On Mon, Feb 13, 2023 at 12:20 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Monday, 13 February 2023 09:09:06 PST Frederick Virchanza Gotham via Std-
> Proposals wrote:
> > Yes. If you have a Labrador object and invoke a member function
> > pointer to "Bark" on it then it will block. But if you apply this same
> > member function pointer to an object of type Dog or BlackLabrador,
> > then it won't block.
>
> This necessarily implies the solution is "callee blocks" (after call
> received), not "caller blocks" (before placing the call). In other words, the
> caller knows absolutely nothing about whether the callee will block or not,
> thereby also allowing pointers to such functions to be stored in regular,
> existing function pointers.
>
> But as a consequence, this means you have nothing more than syntactic sugar to
> implement a mutex, even though it must be in the class layout.
>
> Because the mutex is hidden, it also prevents reordering them to optimise
> member access, prevent false cacheline sharing, or sharing the mutexes between
> multiple functions that may need to block any and all of them. That makes it
> impossible to move said mutex to a private-implementation class so that they
> can be added or removed at will without changing the public class and
> retaining binary compatibility. It also prevents early releasing of the mutex
> when the contention has been dealt with, or late acquisition of the mutex
> after input validation.
>
> Please address these concerns in your paper.

It also prevents implementing the mutex through a heap-allocated
object with a pointer in the class, so that the class can still be
moved.