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 lockelision with TSX


On Sat, Dec 22, 2012 at 07:40:44PM -0800, Andi Kleen wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> >
> > This kind of non-conformant behavior makes it unacceptable for elision
> > to be enabled by default.
> 
> There's nothing non-conformant in lock elision as far as I know,
> all behavior is within POSIX semantics (i.e. within undefinedness)

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.

> > Is there any way around it?
> 
> Generally no (except for the cases I mentioned)
> 
> Is there anything that worries you particularly, as in do you
> have a real program that would be affected by any of this?

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

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
can't just say "we're going to break the interface contract because we
think nobody will notice". 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?

Rich


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