[PATCH v2] nptl: Optimize trylock for high cache contention workloads (BZ #33704)

[Sunil Pandey]

Maybe we can do PTHREAD_MUTEX_RECURSIVE_NP in a separate patch after the
2.43 release, as it requires more
 time testing, debugging and benchmarking.

--Sunil

On Mon, Dec 15, 2025 at 4:17 PM Pandey, Sunil K <sunil.k.pandey@intel.com>
wrote:

> Hi Wilco,
>
> Yes, PTHREAD_MUTEX_RECURSIVE_NP should also benefit from this change since
> the logic is similar. I don't have a strong
>  opinion on this, as we don't currently have any real-world test cases
> available for PTHREAD_MUTEX_RECURSIVE_NP.
>
> I ran a quick check and found that it doesn't make any difference in code
> size on x86 - the changes are absorbed by
>  alignment adjustments.
>
> Please let me know if this change looks acceptable to you. If so, I can
> update it to v3.
>
> Thanks,
> Sunil
>
> $ git diff origin/master
> diff --git a/nptl/pthread_mutex_trylock.c b/nptl/pthread_mutex_trylock.c
> index 94621cc254..ae22b83400 100644
> --- a/nptl/pthread_mutex_trylock.c
> +++ b/nptl/pthread_mutex_trylock.c
> @@ -47,7 +47,8 @@ ___pthread_mutex_trylock (pthread_mutex_t *mutex)
>           return 0;
>         }
>
> -      if (lll_trylock (mutex->__data.__lock) == 0)
> +      if (atomic_load_relaxed (&(mutex->__data.__lock)) != 0
> +         || lll_trylock (mutex->__data.__lock) == 0)
>         {
>           /* Record the ownership.  */
>           mutex->__data.__owner = id;
> @@ -60,7 +61,10 @@ ___pthread_mutex_trylock (pthread_mutex_t *mutex)
>      case PTHREAD_MUTEX_TIMED_NP:
>      case PTHREAD_MUTEX_ADAPTIVE_NP:
>      case PTHREAD_MUTEX_ERRORCHECK_NP:
> -      if (lll_trylock (mutex->__data.__lock) != 0)
> +      /* Mutex type is already loaded, lock check overhead should
> +         be minimal.  */
> +      if (atomic_load_relaxed (&(mutex->__data.__lock)) != 0
> +         || lll_trylock (mutex->__data.__lock) != 0)
>         break;
>
>        /* Record the ownership.  */
>
>
>
>
>
>
> -----Original Message-----
> From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
> Sent: Monday, December 15, 2025 1:25 PM
> To: Pandey, Sunil K <sunil.k.pandey@intel.com>
> Cc: GNU C Library <libc-alpha@sourceware.org>
> Subject: [PATCH v2] nptl: Optimize trylock for high cache contention
> workloads (BZ #33704)
>
> Hi Sunil,
>
> This looks good to me. However is there a reason not to do the same for
> the PTHREAD_MUTEX_RECURSIVE_NP case? That uses the same lll_trylock
> approach (and it would be nice to use more similar logic for both cases).
>
> Cheers,
> Wilco
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251215/8272d4f2/attachment.htm>