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: TSX lock elision for glibc v12


On Fri, 2013-06-21 at 19:27 +0200, Andi Kleen wrote:
> > I don't want to change or expose anything externally if I don't have to.
> > This will make it easier for us to just enable elision without risking
> > to have to maintain other interfaces, break ABIs, etc.
> 
> I don't see the point of checking a new number on all the fast paths
> when it doesn't do anything different.

It adds a distinction that we have to adhere to whenever we want to do
elision.  When you represent it with flags you make the same
distinction.  But a single new type is better.  The one
PTHREAD_MUTEX_DEFAULT_INT_NP alias is just to make it clear that this is
not a TIMED_NP mutex or such, but has DEFAULT semantics.

The flags can be combined with other things in your patch set.  That's
more different states, actually.

Finally, we don't do anything with it yet because it's *obviously* a
distinction added for elision.  Once you use elision, you will treat
PTHREAD_MUTEX_DEFAULT_INT_NP and PTHREAD_MUTEX_NORMAL_INT_NP
differently.

> With elision it's just the same as TIMED_NP | NO_ELISION 
> 
> So why not use that internally?

First of all, there's no consensus to expose any of the elision flags
externally.  So they would have to be internal flags.  And if users
can't set them, it's *much* cleaner to just make the single distinction
that we didn't do (split out PTHREAD_MUTEX_NORMAL_INT_NP) and which
prevents us to use elision widely.

Second, this is not necessarily useful for just elision.  Also see
Roland's comments about that.




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