From owner-freebsd-hackers Mon Feb 5 4:57:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CB03A37B6A2 for ; Mon, 5 Feb 2001 04:57:14 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA12463; Mon, 5 Feb 2001 07:56:39 -0500 (EST) Date: Mon, 5 Feb 2001 07:56:39 -0500 (EST) From: Daniel Eischen To: "Paul D. Schmidt" Cc: hackers@FreeBSD.ORG Subject: Re: known pthread bug? In-Reply-To: <20010204232301.C30977@uberhacker.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 4 Feb 2001, Paul D. Schmidt wrote: > Are there currently any known bugs with pthread_mutex_init > and pthread_cond_init returning 0, but pthread_cond_wait > returning EINVAL nonetheless? Yes, it's a known bug with the _application_ ;-) pthread_cond_[timed]wait must be called with a mutex and that must be the only mutex used with that condition variable. For instance: pthread_mutex_t m1, m2; pthread_cond_t cv; thread 1: pthread_mutex_lock(&m1); ret = pthread_cond_wait(&cv, &m1); pthread_mutex_unlock(&m1); thread 2: pthread_mutex_lock(&m2); ret = pthread_cond_wait(&cv, &m2); pthread_mutex_unlock(&m2); can result in one of the threads returning EINVAL from pthread_cond_wait if one thread is already waiting on the condition variable when the other thread calls pthread_cond_wait(). There is no problem if only one thread is waiting on the condition variable at any one time, but that still should be avoided. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message