This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Andi Kleen <andi at firstfloor dot org>, "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2013 17:28:15 +0200
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <20130624203147 dot GO5643 at tassilo dot jf dot intel dot com> <51C8B797 dot 7080503 at redhat dot com> <20130624232607 dot GT6123 at two dot firstfloor dot org> <51C9B7D0 dot 5000207 at redhat dot com> <20130625170656 dot GB6123 at two dot firstfloor dot org> <20130625173203 dot GL29800 at brightrain dot aerifal dot cx> <20130625204013 dot GS5643 at tassilo dot jf dot intel dot com> <1372197850 dot 964 dot 9938 dot camel at triegel dot csb> <20130626003555 dot GT5643 at tassilo dot jf dot intel dot com> <1372235629 dot 964 dot 10004 dot camel at triegel dot csb> <20130626145934 dot GU5643 at tassilo dot jf dot intel dot com>
On Wed, 2013-06-26 at 07:59 -0700, Andi Kleen wrote:
> > I really get the impression you're not reading reviews. At least you
> > seem to be ignoring mine. Have a look at my reply to your top-most
> > email in the v10 patch set:
> > http://sourceware.org/ml/libc-alpha/2013-06/msg00500.html
> > Look at point 2). There's 4 paragraphs just about this.
>
> You're basically saying I should have separate lock types instead
> of flags.
No, I'm not. First, I said that *if* you want to add new lock types,
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.
> 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?
> So whether it acts like HLE and RTM is undefined.
Do you mean "HLE *or* RTM"? What does "it" refer to?
> 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?