This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Lock elision implementation guidelines


On Wed, Feb 20, 2013 at 11:35:35AM +0100, Torvald Riegel wrote:
> 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.

I think that deadlock requirement is a red-hering. If that is really
in the text should go to the Austin commitee and ask for clarification.
I cannot imagine they really meant that.

Just imagine seriously telling someone:
"we made locking XX% slower to preserve deadlocks"

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

The plan was always to work with existing binaries.

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

You normally need to spin reading, to prevent a flood of unnecessary
cache line conflicts. Even with backoffs that works much better.

The only way to do that with pthread locks is to use a wrapper lock
with own atomic and only take the mutex if that fails.

RTM would need to abort for the read lock operation, so it's good
to not have it for elision. On the other hand it encourages people to write
their own wrapper lock which need explicit eliding, so it's also
bad. But when a is_locked() operation is available lots of programmers
tend to sprinkle it in asserts all over, which is bad again for elision
(and not a good idea anyways, can be done better by static tools)

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]