This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 07/15] Add the low level infrastructure for pthreadslock elision with TSX
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org
- Date: Fri, 11 Jan 2013 15:38:50 +0100
- Subject: Re: [PATCH 07/15] Add the low level infrastructure for pthreadslock elision with TSX
- References: <firstname.lastname@example.org> <email@example.com> <20121223031117.GX20323@brightrain.aerifal.cx> <firstname.lastname@example.org> <20121223035402.GY20323@brightrain.aerifal.cx> <email@example.com> <20121223043045.GZ20323@brightrain.aerifal.cx>
On Sat, 2012-12-22 at 23:30 -0500, Rich Felker wrote:
> On Sat, Dec 22, 2012 at 08:10:27PM -0800, Andi Kleen wrote:
> > Rich Felker <firstname.lastname@example.org> 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.
> > 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).
It is necessary to eventually stop trying elision and falling back to
nonspeculative execution because TSX doesn't have any forward progress
guarantee according to its spec (even in the absence of contention).