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: Rich Felker <dalias at aerifal dot cx>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Andi Kleen <ak at linux dot jf dot intel dot com>, libc-alpha at sourceware dot org
- Date: Tue, 25 Jun 2013 13:32:03 -0400
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <1372105055-31254-1-git-send-email-andi at firstfloor dot org> <51C8AB50 dot 80108 at redhat dot com> <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>
On Tue, Jun 25, 2013 at 07:06:56PM +0200, 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?
>
> AFAIK glibc is adding new ABIs all the time, there was just a new
> one last week.
It's not a problem, but I believe the roadmap for committing elision
is to start with changes that don't affect ABI (and thus don't commit
glibc to any particual course of action) so we can narrow down the
very small amount of stuff that will affect ABI for final review once
the "safe" stuff is already done.
> commit 61dd6208fb1e59a423b6dfa712a3c896c34b2590
> Author: Siddhesh Poyarekar <siddhesh@redhat.com>
> 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?
A new API is very different from a new ABI version of an existing API.
> > 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.
Note the "in this first pass".
Also, the tuning per-lock is not nearly as impactful as adding mutex
type constants or changing the meaning of existing ones in subtle
ways. Adding these new tuning functions will not affect any
application that does not use them, i.e. any current application and
any conforming POSIX application. On the other hand, changing NORMAL
will affect many applications.
> 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
I understand you're a bit frustrated, but this is a complex change to
get right, and I hope you can respect that some of us who even aren't
so fond of the feature in itself are working on coming up with
solutions that are safe and responsible to everybody's legitimate
needs and expectations for the behavior of the standard library. I
think we've made a lot of progress, and the rest will be able to
proceed in a way that meets all your goals; the main thing right now
is factoring it into the for-immediate-commit parts and the parts that
still require some resolution with respect to the NORMAL issue or
other issues with ABI impact, if there are any.
Rich