Date: Mon, 19 Oct 1998 15:26:27 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: current@FreeBSD.ORG, info@highwind.com Subject: Re: Another Serious libc_r problem Message-ID: <199810191926.PAA10944@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> We found another libc_r problem which is spinning the CPU at 100%.
> This makes it impossible for our application to work at all.
>
> FreeBSD 3.0 kernel from August. The LATEST libc_r. Tested this on
> another FreeBSD with a much more recent kernel. Same result. The CPU
> spins and the threads don't get the condition.
I believe your test program is in error. Your threads are
not ever going to awake from the pthread_cond_wait() statement
because the mutex cannot be acquired. Your main thread locks
the mutex and never unlocks it.
If this application works on other operating systems, it seems
that they are at fault. From the Solaris pthread_cond_wait manpage:
A condition variable enables threads to atomically block and
test the condition under the protection of a mutual exclu-
sion lock (mutex) until the condition is satisfied. If the
condition is false, a thread blocks on a condition variable
and atomically releases the mutex that is waiting for the
condition to change. If another thread changes the condi-
tion, it may wake up waiting threads by signaling the asso-
ciated condition variable. The waiting threads, upon awak-
ening, reacquire the mutex and re-evaluate the condition.
Here's a patch to make your test program do what I think it
is suppose to:
*** condWaitBug.C.orig Mon Oct 19 15:00:28 1998
--- condWaitBug.C Mon Oct 19 15:02:37 1998
***************
*** 26,32 ****
--- 26,34 ----
{
// Wait until we are signalled, then print.
while (true) {
+ assert(!::pthread_mutex_lock(&lock));
assert(!::pthread_cond_wait(&condition, &lock));
+ assert(!::pthread_mutex_unlock(&lock));
::printf("Got Condition!\n");
}
}
***************
*** 57,62 ****
--- 59,67 ----
assert(!::pthread_attr_destroy(&attr));
}
+ // Unlock the lock
+ assert(!::pthread_mutex_unlock(&lock));
+
// Sleep for 3 seconds to make sure the threads started up.
timeval timeout;
timeout.tv_sec = 3;
> On FreeBSD 3.0, it prints "Signalling" twice and then spins the CPU.
This didn't happen to me on a recent -stable. There were some
recent fixes to 3.0 libc_r for incremental priority updates that
were not being properly computed.
Dan Eischen
eischen@vigrid.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810191926.PAA10944>