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: kemi <kemi dot wang at intel dot com>
- To: Carlos O'Donell <carlos at redhat 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 15:42:57 +0800
- 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 2018年07月06日 09:32, 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.
>>
>
BTW, I can separate 1/4 patch into several sub-patches if you think it would
be easier for 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.
>
>
>> 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.
>
> 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.
>
>>