Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Carlos O'Donell <carlos <at> redhat.com>
Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
Newsgroups: gmane.comp.lib.glibc.alpha
Date: Wednesday 26th June 2013 22:06:13 UTC (over 4 years ago)
On 06/25/2013 01:06 PM, Andi Kleen wrote:
>> So I've done some more work on this last night.
>>
>> The problem with continuing down this path is that it creates an ABI
>> event by exposing NORMAL as a new external type.
> 
> Can you explain why this is a problem?

The discussion around the new type might take more time
than we have before the 2.18 freeze.

> AFAIK glibc is adding new ABIs all the time, there was just a new
> one last week.
> 
> commit 61dd6208fb1e59a423b6dfa712a3c896c34b2590
> Author: Siddhesh Poyarekar 
> Date:   Sat Jun 15 12:24:15 2013 +0530
> 
>     New API to set default thread attributes
> 
> 
> Why are any additions I make suddenly such a big problem?

Two new symbols took months of work to iron out the details,
just go back and look at the long threads between Roland,
Siddhesh, and Rich.

Not to mention that these symbols are completely new and
don't interfere with existing programs in any way.

Your changes are to existing interfaces and we must be even
more careful there.

That is why I'm recommending starting with a base patch that
just adds elision for the default mutex type when we build
with --enable-elision=yes.
 
>>
>> I looked at the generated code for adding NORMAL as an internal type
>> and ran some crude benchmarks and the performance difference is in the
>> noise.
>>
>> What I'm trying to balance is:
>>
>> * Avoid ABI changes in this first pass.
> 
> 
> Sorry I don't think we will get anywhere with such a requirement
> The tuning bits per lock are not negotiable for me. 

That's fine, you are entitled to your opion,
and we can discuss that as a second step.

I hope that you would agree that it would be better for
everyone if we could at least get elision support for 
default via --enable-elision=yes?

I'd rather this, since it creates a smaller second patch
to review given that the core elision routines are
all already included.

> The NORMAL change I would be ok to remove again (if elision 
> stays), but I assume that would make Rich et.al. unhappy.
> 
> I'm also starting to get concerned by the constantly shifting
requirements

That is entirely our fault, and I'm mostly to blame for that.

We haven't merged something of this complexity in a long time.

Please bear with us as we get better with the process.

Cheers,
Carlos.
 
CD: 17ms