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

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

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?

> Things that could be added / changed:
> * We could try to not subsume explicitly initialized DEFAULT mutexes
> under the NORMAL mutexes.  But this seems to require bumping symbol
> versions.  So might not be worth it.

.

> 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.

> 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.  Really, I'm not questioning this just for fun
but because I've been testing transactional memory and lock
elision on z/archirecture for several month, and because of the
test results I'm much less optimistic that any _existing_
application will get any relevant benefit from elision for free.
I rather expect that some applications can be (and have to be)
carefully reworked to yield these benefits, while other
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.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany