summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDavid Chisnall <csdavec@swan.ac.uk>2013-02-19 11:28:45 +0000
committerDavid Chisnall <csdavec@swan.ac.uk>2013-02-19 11:28:45 +0000
commit8b6a4de64a13a57c8c3233b4fc6f74d892c6b2b1 (patch)
tree06573cb5881dfec81516d01d32bd19302645746f
parentd26b3334b1e9bac59f56718329b9648d8d85fd86 (diff)
downloadbcm5719-llvm-8b6a4de64a13a57c8c3233b4fc6f74d892c6b2b1.tar.gz
bcm5719-llvm-8b6a4de64a13a57c8c3233b4fc6f74d892c6b2b1.zip
Fix a bug in mutex_try_to_lock. This was previously trying to unlock a mutex that it didn't own, causing an assertion failure in mutex.cpp. The issue was that the unique_lock went out of scope, releasing the lock on m, then m.unlock() was called on an already-unlocked mutex.
This change removes the spurious m.unlock() call. If this test was previously passing for anyone with assertions enabled, then they should investigate bugs in their pthread implementation, as pthread_unlock() should not return 0 if the mutex is currently unlocked. llvm-svn: 175506
-rw-r--r--libcxx/test/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_try_to_lock.pass.cpp1
1 files changed, 0 insertions, 1 deletions
diff --git a/libcxx/test/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_try_to_lock.pass.cpp b/libcxx/test/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_try_to_lock.pass.cpp
index 52815071e9c..b6c64f50404 100644
--- a/libcxx/test/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_try_to_lock.pass.cpp
+++ b/libcxx/test/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_try_to_lock.pass.cpp
@@ -48,7 +48,6 @@ void f()
break;
}
time_point t1 = Clock::now();
- m.unlock();
ns d = t1 - t0 - ms(250);
assert(d < ms(200)); // within 200ms
}
OpenPOWER on IntegriCloud