On Monday, 13 February 2023 11:43:20 PST Jason McKesson via Std-Proposals
wrote:
> > 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.

Another one: it prevents choosing what type of mutex to use. For example, you
could choose an adaptive one that has a spinlock loop to attempt to acquire
instead of giving up and waiting on a system call. Or just a plain spinlock,
which is much smaller (1 byte instead of 40).

Admittedly, this applies to the static threadsafe initialisation too and no
one has asked for this type of fine-tuning (that I know of).

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