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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering