From owner-freebsd-current Wed Oct 21 08:19:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA29895 for freebsd-current-outgoing; Wed, 21 Oct 1998 08:19:33 -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 IAA29886 for ; Wed, 21 Oct 1998 08:19:31 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id LAA07958; Wed, 21 Oct 1998 11:19:01 -0400 (EDT) Date: Wed, 21 Oct 1998 11:19:01 -0400 (EDT) From: Daniel Eischen Message-Id: <199810211519.LAA07958@pcnet1.pcnet.com> To: eischen@vigrid.com, lists@tar.com Subject: Re: Another Serious libc_r problem Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >If the thread doesn't own the mutex, then you've got the > >condition variable locked while you're waiting for the > >pthread_mutex_unlock(). Since this falls into the category > >of "undefined behavior" it probably doesn't matter though. > > However, the thread should own the mutex shouldn't it? I thought > the spec for pthread_cond_wait says it should return EINVAL if > the thread doesn't own the mutex? However, its not clear to > me that our pthread_cond_wait code makes this check (I think > it doesn't). Yeah, we're saying the same thing. The thread *should* own the mutex, and then your solution works. If it doesn't own the mutex, then you've got a potential deadlock condition, but this could be deemed acceptable because POSIX says that "undefined behavior" will occur in this case. I don't have the POSIX spec handy, but I think you're right in that pthread_cond_wait should return EINVAL if the thread doesn't own the mutex. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message