Re: [RFC] Lock elision implementation guidelines

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2013-02-19 at 22:11 +0100, Andi Kleen wrote:
> > That's a good counter example -- I hadn't thought about signal handling.
> 
> Any signal will abort of course.
> 
> > The same question also applies to program exit: Is a program with a
> 
> Program exit will also abort.

I've thought about both cases before, in particular the case of HTMs
like Intel RTM that don't let any side effects escape.  This may seem
sufficient at first, but the problem is that we can't know whether
continuing to execute the program when it should in fact deadlock will
not commit the transaction.

Consider this contrived example

void foo(bool some_condition)
{
  if (some_condition)
    {
      pthread_mutex_lock(&m); pthread_mutex_lock(&m);
      // Should deadlock and not continue any further
    }
  do_something_else();
  // Release two other locks.
  pthread_mutex_unlock(&m1);
  pthread_mutex_unlock(&m2);
  // Not in a transaction anymore...
}
  

> > Andi: do you see any reasons why this would be really helpful for
> > experimentation (i.e., helpful enough to justify carrying this "hack"
> > around in glibc)?
> 
> Not sure what hack you mean.

For a standards-conformant solution, we need to make
PTHREAD_MUTEX_DEFAULT different from PTHREAD_MUTEX_NORMAL, which
includes changing the default initializer.  Thus, you need to compile
applications against a new glibc to enable default mutexes to use
elision.  The "hack" would be a switch (e.g., an env var) that would
ignore the deadlock requirement for NORMAL mutexes, meaning that you
could experiment with elision in applications you haven't recompiled.

But perhaps that's better served by providing a modified glibc anyway,
at least as far as upstream glibc is concerned.

> I don't have plans to implement deadlocks
> deliberately. Iff the standard really requires that I would consider
> it a defect in the standard.

Well, it's a choice that can make sense, not necessarily a defect.  If
you want to argue with the Austin Group about that, please do so.  Just
have a look at the definition of NORMAL vs. DEFAULT mutexes.

The problem that we face is that in the current glibc implementation
both DEFAULT and NORMAL mutexes are treated the same, which isn't
helpful anymore once lock elision needs to be considered.  The default
mutex type (e.g., with default initializers) is still DEFAULT, so
something for which we can use elision based on HTMs.  But we need to
recompile applications with a newer glibc for that (in particular to
have mutexes with default initializers get the new type default type
that's different from NORMAL).

> > So, while I agree that we want to avoid making people write their own
> > lock implementations, I don't see anything wrong with them actually
> > doing that in cases where it's beneficial for them and they want to do
> > better than the one-size-fits-all automatic tuning.
> 
> Note that POSIX pthreads does not export enough primitives for
> efficient spinning.  However that's good for lock elision.

Can you elaborate?  You can both do a trylock() and block, so it seems
most of it is there in principal.  There's no getlock() or something
like that with which you could do test-and-test-and-set like locks, but
OTOH perhaps you can get as similar effect with backoff.


Torvald