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: [PATCH 07/15] Add the low level infrastructure for pthreads lock elision with TSX


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.

> 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. 
I claim it's conformant yes.

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

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

> As for the conformance issue, I haven't thought about real-world
> usages it would break, but the burden of proof is on your side. You

I don't know of any with trylock. I really listed it only for
completeness, personally I think trylock is a non issue.

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

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

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