Re: [PATCH 07/15] Add the low level infrastructure for pthreads lockelision with TSX

[Rich Felker <dalias at aerifal dot cx>]

On Sat, Dec 22, 2012 at 09:40:50PM -0800, Andi Kleen wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> 
> >> I claim it's conformant yes.
> >
> > Unless there's some loophole that makes calling pthread_mutex_trylock
> > on a regular mutex you already hold undefined behavior, I claim you're
> > wrong. And I can't find any such loophole.
> 
> I would claim to be at least covered by the rationale, but ok.
> Too bad it's a shall.
> 
> Can you point me to any real software impacted by this?
> 
> In the worst case we can make trylock aborting, but I'm unwilling 
> to do that without evidence that it is a real problem.
> 
> >> > From a practical standpoint, I'm more worried about the cost of
> >> > re-running twice every block of code that takes a mutex and does
> >> > something nontrivial with it. Unless I misunderstand, elided locks
> >> > should only perform well in the case where they're held for a very
> >> > short time. What happens if a syscall is made during that time? Am I
> >> > correct in assuming the overhead of enterring kernelspace occurs
> >> > twice?
> >> 
> >> It doesn't.
> >> 
> >> The syscall aborts immediately and for an internal abort like this
> >> the adaptation algorithm in the mutex lock stops eliding for some time.
> >
> > Does it abort before any cost is incurred, though?
> 
> A common case is that speculation happens in the time 
> when you would block anyways.
> 
> That's not always the case, that is why we have adaptive locks
> that stop eliding when not profitable.

I admit I haven't read all the source; how do you do that without
storing significant additional information in the fixed-size mutex
structure, which is already almost full? I would assume with minimal
state space, the choice would have to be global for the lock, not
local for each place it's locked from, which might preclude using lock
elision in a lot of cases.

> > Well I'm open to less-expensive solutions as long as they deliver
> > conforming behavior.
> 
> It would be possible to make trylock elide only when the lock is forced
> to elision explicitely, and otherwise abort. 

This is certainly one approach. Is it not possible to arrange for the
speculative execution to see the lock as locked, perhaps with some
trick other than modifying the data at the actual atomic lock/futex
address?

> I would need a third per lock status bit for that and it would
> complicate everything somewhat. It also would mean that all programs
> that want trylock elision would need to be modified.  So it would have a
> high programmer cost.

"All programs that want to use a particular performance optimization
have to be modified" is certainly a smaller cost than "all
multi-threaded programs need to be audited for dependence on
implementaiton behavior that the standard requires and that glibc has
historically guaranteed; failure to do this audit could result in
random and unpredictable breakage".

I understand your enthusiasm for getting this integrated, but I don't
think it should be at the expense of correctness and potentially
dangerous breakage.

Rich