Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT

[Andi Kleen <ak at linux dot jf dot intel dot com>]

> No, I'm not.  First, I said that *if* you want to add new lock types,

I cannot deal with hypotheticals. Please make only concrete and 
implementable suggestions.

> you should target the C++11 semantics.  That doesn't mean that we do add
> new lock types now.  Second, performance hints don't require new
> semantics (ie, new types); I said that any elision flags that we might
> have should be performance hints (ie, don't change semantics).  That
> still doesn't say that we have consensus for any interface for making
> per-lock performance hints.

If elision is disabled as default, there needs to be some way
to enable it per lock.  So an enable bit is needed.

If elision is enabled by default, there needs to be some way to disable
elision. So a disable bit is needed.

That is what I have. I don't see how I can make it any simpler.
I'm sure there are lots of ways to make it more complex.

I overloaded the enable bit with enabling nesting on trylock.
I did that to minimize the size of the new API. If people
prefer to have it a separate bit (or type) I'm also ok with that.

I originally defaulted any elided lock acting like a recursive lock,
but people didn't like it, so the default doesn't nest trylock.

The use case of nesting for trylock is imho
important because it seems to be a common (even if poor) use case to
use trylock as a spin frontend for pthread_mutex_lock(). 
If people do that, they could never nest their locks with elision.

So there needs to be at least some way to enable this.

> > As for HLE vs RTM semantics, I consider nested trylock undefined
> > with elision.
> 
> I don't understand this sentence.  Undefined from which/whose point of
> view?

The recursive semantics of the elided lock (be it either a type or a flag) is 
undefined. That's similar to DEFAULT.

> 
> > So whether it acts like HLE and RTM is undefined.
> 
> Do you mean "HLE *or* RTM"?  What does "it" refer to?

Yes or. It is the elided lock type/flag.

> 
> > In terms of hardware HLE will never nest as deeply as RTM can,
> > because each nesting level needs hardware resources (a lock buffer)
> > So it's unlikely HLE will ever nest as deep as RTM can.
> 
> So?  Maybe HLE won't work for long chains of hand-over-hand locking, but
> it would be reasonable to assume that it works for a few nested critical
> sections, right?

I assume there will be always software with deeper nesting than what
reasonable hardware can provide. Software is getting more complex all
the time too.

-Andi