Re: [PATCH] Lock elision: Give PTHREAD_MUTEX_NORMAL-like mutexes a new internal type.

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Jun 25, 2013 at 08:49:47AM +0200, Dominik Vogt wrote:
> On Sat, Jun 22, 2013 at 01:04:58AM +0200, Torvald Riegel wrote:
> > Shortcomings:
> > * Mutexes _explicitly_ initialized to PTHREAD_MUTEX_DEFAULT via
> > pthread_mutex_settype are treated like PTHREAD_MUTEX_NORMAL.  This is
> > correct because DEFAULT provides strictly weaker guarantees, but means
> > that we can't use elision for those mutexes.  However, setting this
> > explicitly is redundant, and probably used rarely.
> 
> Is it really acceptable if mutexes that are _implicitly_
> initilized to PTHREAD_MUTEX_DEFAULT use different semantics than
> mutexes initialized _explicitly_ to PTHREAD_MUTEX_DEFAULT ->
> PTHREAD_MUTEX_NORMAL?

Sure. The behavior on double-lock or incorrect-unlock is UNDEFINED for
DEFAULT type mutexes. This means it's perfectly acceptable for them to
deadlock under some circumstances, crash under others, and do anything
else reasonable or unreasonable under others. And there's no
obligation for any implementation to document such behavior since it's
undefined. This is exactly the kind of
freedom/flexibility/optimization that undefined behavior exists for.

> > The main motivation for this patch, besides solving the technical
> > problem it addresses, is to carve out the parts of Andi's patches that
> > we can hopefully reach consensus on *now*.
> 
> Actually, I don't understand this pressure to get _something_ into
> 2.18 when it's clear that there will be no *well tested* elision
> patches and there's a risk to shoot your own foot.

There is unlikely to be any major testing before it's in an official
release, since building and installing your own glibc is not a
realistic task for most users.

> > but this gives us the 90% that
> > we're interested in (ie, enabling elision for most mutexes including in
> > existing binaries),
> 
> How can we know what we're interested with zero performance
> testing up to now.

I tend to agree the possibility is strong that lock elision is not
beneficial to 90-100% of real-world usage cases, but it seems there's
fairly strong interest in testing whether it is or not by implementing
it in glibc. Personally I'm not really against this since I'll end up
getting some real-world performance figures on which to base a
decision of whether elision ever belongs in musl. :-)

Also, even if it's not beneficial for most mutex uses, it might really
help for glibc-internal use in situations where libc interfaces need
locking, like some malloc invocations, timezone access, etc..

> applications will never get them.  Please keep in mind that lock
> elision is not a magical wand that fixes every lock related
> performance problem without ever understanding what the problem
> was in the first place.

Indeed, I suspect in many cases it makes things _worse_, especially in
the case of varying thread priorities. We may find that for
conformance, or just tolerable lock acquisition order, it's necessary
to disable elision for pshared synchronization objects (where it's
impossible to tell if different priority threads may be accessing it)
and whenever the process has used functions that result in threads of
different priorities existing in the same process.

Rich