This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC 0/4] Add a new mutex type PTHREAD_MUTEX_QUEUESPINNER_NP
- From: Carlos O'Donell <carlos at redhat dot com>
- To: kemi <kemi dot wang at intel dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Rical Jason <rj at 2c3t dot io>, Glibc alpha <libc-alpha at sourceware dot org>
- Cc: Dave Hansen <dave dot hansen at linux dot intel dot com>, Tim Chen <tim dot c dot chen at intel dot com>, Andi Kleen <andi dot kleen at intel dot com>, Ying Huang <ying dot huang at intel dot com>, Aaron Lu <aaron dot lu at intel dot com>, Lu Aubrey <aubrey dot li at intel dot com>
- Date: Fri, 6 Jul 2018 08:42:34 -0400
- Subject: Re: [RFC 0/4] Add a new mutex type PTHREAD_MUTEX_QUEUESPINNER_NP
- References: <1530519116-13103-1-git-send-email-kemi.wang@intel.com> <11b23352-762c-3f35-8bbf-da9fbfef075c@redhat.com> <4b86721b-56f0-2968-305e-176198cf2cf8@intel.com>
On 07/05/2018 09:32 PM, kemi wrote:
>
>
> On 2018年07月06日 04:12, Carlos O'Donell wrote:
>> On 07/02/2018 04:11 AM, Kemi Wang wrote:
>>> The pthread adaptive mutex is designed based-on the truth that the lock
>>> probably would be released after a few of CPU cycles in most cases.
>>> Especially for the case: the applications code is well-behaved with a short
>>> critical section that is highly contended. Thus, spinning on the lock for
>>> a while instead of calling into the kernel to block immediately can help
>>> to improve the system performance.
>>
>> This patch set is going to take a while to review.
>>
>
> Yes. Thanks for taking your time to review!
>
>> We are currently freezing the ABI/API for glibc 2.28 release on August 1st.
>>
>
> I know. This patch series introduces a new mutex type and would not break the
> existed ABI/API.
You don't break the ABI, but you do change it with the addition of a constant
PTHREAD_MUTEX_QUEUESPINNER_NP in the public pthread.h headers.
In theory this makes it OK for backport to the various distributions, since
the constant addition is not tied to any versioned symbol and is simply a flag
that you pass into the existing implementation. Your program has to be able to
handle failure if you request this type and don't get it.
>> Are you OK if we delay the inclusion of this feature to 2.29 once master
>> reopens?
>
> I hope we can pick this feature before 2.28 release if you are comfortable.
It's very unlikely to happen. I wand to set that expectation up front.
We have only 3 weeks to get through the other issues that have been waiting
longer in the queue than this, namely Intel CET, C11 threads, etc, everything
you see here:
https://sourceware.org/glibc/wiki/Release/2.28#Planning
> The new mutex type would benefit some guys who have severe lock contention in
> their applications (Actually, some of our customers have complained to us). And
> we can keep improving this feature after 2.28 release later.
Given that distributions could backport this (no new symbols, just a new flag),
is there really any rush in getting it reviewed?
--
Cheers,
Carlos.