From 870bd84a4ee53ea98fd232da18771b1525dac1a1 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Sat, 11 Aug 2012 14:08:39 +0200 Subject: 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 Reviewed-by: Marc Mutz --- src/corelib/thread/qmutex_linux.cpp | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'src') diff --git a/src/corelib/thread/qmutex_linux.cpp b/src/corelib/thread/qmutex_linux.cpp index e14660cc37..09db046f0f 100644 --- 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(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; -- cgit v1.2.3