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: Andi Kleen <andi at firstfloor dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, Andi Kleen <ak at linux dot jf dot intel dot com>, libc-alpha at sourceware dot org
- Date: Tue, 25 Jun 2013 19:06:56 +0200
- 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>
> 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.
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?
>
> 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.
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
-Andi