From owner-freebsd-current Mon Oct 19 12:32:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10502 for freebsd-current-outgoing; Mon, 19 Oct 1998 12:32:25 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10341 for ; Mon, 19 Oct 1998 12:30:40 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id PAA10944; Mon, 19 Oct 1998 15:26:27 -0400 (EDT) Date: Mon, 19 Oct 1998 15:26:27 -0400 (EDT) From: Daniel Eischen Message-Id: <199810191926.PAA10944@pcnet1.pcnet.com> To: current@FreeBSD.ORG, info@highwind.com Subject: Re: Another Serious libc_r problem Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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