From owner-freebsd-current Mon Oct 19 13:46:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17335 for freebsd-current-outgoing; Mon, 19 Oct 1998 13:46:27 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from highwind.com (hurricane.highwind.com [209.61.45.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17330 for ; Mon, 19 Oct 1998 13:46:25 -0700 (PDT) (envelope-from info@highwind.com) Received: (from info@localhost) by highwind.com (8.8.6/8.8.6) id QAA21744; Mon, 19 Oct 1998 16:45:32 -0400 (EDT) Date: Mon, 19 Oct 1998 16:45:32 -0400 (EDT) Message-Id: <199810192045.QAA21744@highwind.com> From: HighWind Software Information To: eischen@vigrid.com CC: current@FreeBSD.ORG, bright@hotjobs.com In-reply-to: <199810191926.PAA10944@pcnet1.pcnet.com> (message from Daniel Eischen on Mon, 19 Oct 1998 15:26:27 -0400 (EDT)) Subject: Re: Another Serious libc_r problem Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. I claim that doesn't matter. WHY should the CPU spin if I signal twice on a lock I have? That is PERFECTLY valid. Let's say I want to say that TWO events are ready to be handled. That is perfectly fine. --- Simply to placate your claim, here is another version that locks and unlocks the mutex in proper fashion. I simply had to insert an additional "sleep" to get the bug to appear. In both cases, spinning the CPU at 100% and allowing the program to hang and make no forward progress is a SERIOUS bug. I claim that this new version is 100% valid. Does proper locking, and also works on other O/S's. On FreeBSD it does not work at all. -Rob ------- /* Illustration of FreeBSD pthread_cond_wait() bug This program sets up a conditional wait and fires off a dozen threads that simply wait for the condition. Once the threads are started, the main thread loops signalling the condition once a second. Normally, this should result in "Signalling" and "Got Condition" being printed once a second. However, because of some bugs in FreeBSD, the pthread_cond_wait() spins the CPU and no progress is made. g++ -o condWaitBug -D_REENTRANT -D_THREAD_SAFE -g -Wall condWaitBug.C -pthread */ #include #include #include #include #include pthread_mutex_t lock; pthread_cond_t condition; static void *condThread(void *) { // Wait until we are signalled, then print. while (true) { // Be sure to do proper locking and unlocking assert(!::pthread_mutex_lock(&lock)); assert(!::pthread_cond_wait(&condition, &lock)); ::printf("Got Condition!\n"); assert(!::pthread_mutex_unlock(&lock)); } } int main(int, char **) { // Initialize Lock pthread_mutexattr_t lock_attr; assert(!::pthread_mutexattr_init(&lock_attr)); assert(!::pthread_mutex_init(&lock, &lock_attr)); assert(!::pthread_mutexattr_destroy(&lock_attr)); // Initialize Condition pthread_condattr_t cond_attr; assert(!::pthread_condattr_init(&cond_attr)); assert(!::pthread_cond_init(&condition, &cond_attr)); assert(!::pthread_condattr_destroy(&cond_attr)); // Spawn off a dozen threads to get signalled for (int j = 0; j < 12; ++j) { pthread_t tid; pthread_attr_t attr; assert(!::pthread_attr_init(&attr)); assert(!::pthread_create(&tid, &attr, condThread, 0)); assert(!::pthread_attr_destroy(&attr)); } // Sleep for 3 seconds to make sure the threads started up. timeval timeout; timeout.tv_sec = 3; timeout.tv_usec = 0; ::select(0, 0, 0, 0, &timeout); for (int k = 0; k < 60; ++k) { // Signal while locked assert(!::pthread_mutex_lock(&lock)); ::printf("Signalling\n"); assert(!::pthread_cond_signal(&condition)); // Sleep for 1 second timeout.tv_sec = 1; timeout.tv_usec = 0; ::select(0, 0, 0, 0, &timeout); ::printf("Signalled again\n"); assert(!::pthread_cond_signal(&condition)); assert(!::pthread_mutex_unlock(&lock)); // Sleep for 1 second timeout.tv_sec = 1; timeout.tv_usec = 0; ::select(0, 0, 0, 0, &timeout); } return EXIT_SUCCESS; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message