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

[Pandey, Sunil K]

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