summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authormtm <mtm@FreeBSD.org>2003-07-01 15:52:09 +0000
committermtm <mtm@FreeBSD.org>2003-07-01 15:52:09 +0000
commit1d6d4a9cc046ed3a39348552f8041e06ce4a6b09 (patch)
treefb27322e97ba374135d9225ae92885018f70087e
parent4d495abb9d6f6e6d703264c4133ce1f0c4e7df92 (diff)
downloadFreeBSD-src-1d6d4a9cc046ed3a39348552f8041e06ce4a6b09.zip
FreeBSD-src-1d6d4a9cc046ed3a39348552f8041e06ce4a6b09.tar.gz
Do not attempt to reque a thread on a mutex queue. It may be that
a thread receives a spurious wakeup from sigtimedwait(), so make sure that the call to the queueing code is called only once before entering the loop (not in the loop). This should fix some fatal errors people are seeing with messages stating the thread is already on the mutex queue. These errors may still be triggered from signal handlers; however, since that part of the code is not locked down yet.
-rw-r--r--lib/libthr/thread/thr_mutex.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c
index 7d7c455..3244158 100644
--- a/lib/libthr/thread/thr_mutex.c
+++ b/lib/libthr/thread/thr_mutex.c
@@ -1406,8 +1406,8 @@ get_mcontested(pthread_mutex_t mutexp)
* threads are concerned) setting of the thread state with
* it's status on the mutex queue.
*/
+ mutex_queue_enq(mutexp, curthread);
do {
- mutex_queue_enq(mutexp, curthread);
PTHREAD_SET_STATE(curthread, PS_MUTEX_WAIT);
curthread->data.mutex = mutexp;
_thread_critical_exit(curthread);
OpenPOWER on IntegriCloud