Don't recheck about timeout == 0 during mutex locking

If the timeout wasn't zero, it can only become zero if we return from
futex() with a non-timeout reason but subsequently expires while we're
recalculating something.

A side effect is that we try-lock a non-recursive mutex exactly
once. Before this change, we'd fastTryLock() twice even with
timeout == 0.

Change-Id: I0af09fc2a84669a683a843fcf1513203b075dfb7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>

diff --git a/src/corelib/thread/qmutex_linux.cpp b/src/corelib/thread/qmutex_linux.cpp
index e14660c..09db046 100644 (file)
--- a/src/corelib/thread/qmutex_linux.cpp
+++ b/src/corelib/thread/qmutex_linux.cpp
@@ -123,17 +123,18 @@ bool QBasicMutex::lockInternal(int timeout) Q_DECL_NOTHROW
         return static_cast<QRecursiveMutexPrivate *>(d)->lock(timeout);
     }
 
+    if (timeout == 0)
+        return false;
+
     QElapsedTimer elapsedTimer;
     if (timeout >= 1)
         elapsedTimer.start();
 
     while (!fastTryLock()) {
         d = d_ptr.load();
+
         if (!d) // if d is 0, the mutex is unlocked
             continue;
-        if (timeout == 0)
-            return false;
-
         // the mutex is locked already, set a bit indicating we're waiting
         while (d_ptr.fetchAndStoreAcquire(dummyFutexValue()) != 0) {
             struct timespec ts, *pts = 0;