From owner-freebsd-hackers Mon Feb 5 13:56:23 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 D952F37B491 for ; Mon, 5 Feb 2001 13:56:02 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA09441; Mon, 5 Feb 2001 16:55:36 -0500 (EST) Date: Mon, 5 Feb 2001 16:55:36 -0500 (EST) From: Daniel Eischen To: Alfred Perlstein Cc: "Paul D. Schmidt" , hackers@FreeBSD.ORG Subject: Re: known pthread bug? In-Reply-To: <20010205113055.T26076@fw.wintelcom.net> 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 Mon, 5 Feb 2001, Alfred Perlstein wrote: > * Paul D. Schmidt [010205 11:15] wrote: > > On Mon, Feb 05, 2001 at 12:59:37AM -0800, Alfred Perlstein wrote: > > > * Paul D. Schmidt [010204 23:23] wrote: > > > > > > Are there currently any known bugs with pthread_mutex_init > > > > and pthread_cond_init returning 0, but pthread_cond_wait > > > > returning EINVAL nonetheless? > > > > > > Can you provide a code sample to replicate this and specify which > > > version of FreeBSD you're using? > > > > typedef struct cond_tag { > > long cond_id; > > char *name; > > > > pthread_mutex_t cond_mutex; > > pthread_cond_t sys_cond; > > } cond_t; > > > > void thread_cond_create(cond_t *cond) > > { > > pthread_cond_init(&cond->sys_cond, NULL); > > pthread_mutex_init(&cond->cond_mutex, NULL); > > } > > > > void thread_cond_wait(cond_t *cond) > > { > > pthread_cond_wait(&cond->sys_cond, &cond->cond_mutex); > > } > > > > pthread_cond_wait() is returning immediately with EINVAL, even though > > printf debugging tells me that both the pthread_(cond|mutex)_init > > functions returned 0 (which man tells me is success). > > > > This is on FreeBSD 4.2-RELEASE. > > 1) 4.2 RELEASE has known pthreads bugs, you should upgrade to -stable. > 2) is cond->cond_mutex held when thread_cond_wait() is called? if not > I'm pretty sure it needs to be. Correct. You must call pthread_cond_wait() with the mutex locked (as specified by POSIX). The whole point of pthread_cond_wait() is to atomically unlock the mutex and wait for an event. If the mutex isn't locked, EINVAL is returned. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message