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 08:10:27PM -0800, Andi Kleen wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> 
> btw I'm not sure if it's the fault of the mailing list, but please
> copy me when replying. I may easily miss replies if they're
> only sent to the list.

OK, will do. Sorry, I normally just hit "reply to list" when using
mailing lists.

> > You just gave an example of non-conformance: pthread_mutex_trylock
> > returning the wrong value. Are you claiming this behavior is
> > conformant for default-type (non-recursive, non-errorcheck) mutexes?
> > My reading of POSIX is that it's not; for pthread_mutex_trylock, EBUSY
> > is a "shall fail" error.
> 
> If it's actually busy, but with elision it is not. 

In the abstract machine, it is busy. Upon successful return from
pthread_mutex_lock, the calling thread shall hold the lock. The fact
that you have an implementation where this requirement is satisfied in
a way that doesn't look like a traditional "holding the lock" state
does not absolve you of the requirement to deliver behavior as if
things took place as specified in the abstract machine.

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

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

> The rwlocks currently don't do that, but I expect that will be fixed at
> some point.

I think important for rwlocks, since a very reasonable usage case is
to do a lot of work while the read lock is held, under the assumption
that write locks are very rare (for example if the write lock is only
held when a config file has changed, to reload the new config).

> > can't just say "we're going to break the interface contract because we
> > think nobody will notice".
> 
> The interface contract as I see it is to avoid deadlock, and that
> is not violated.

No, the interface contract is much more detailed and laid out in
POSIX. It includes such requirements as the one that
pthread_mutex_trylock return EBUSY when the mutex is already held,
unless the mutex is recursive and the calling thread is the owner.

> > If there's no other fix, shouldn't it be
> > possible to just make pthread_mutex_trylock under elided-lock cause
> > restart with a real lock?
> 
> You could abort in trylock, but that would mean no-one using trylock
> would ever elide, which would prevent a lot of real programs from using
> elision.

Well I'm open to less-expensive solutions as long as they deliver
conforming behavior.

Rich