From owner-freebsd-current Wed Oct 21 07:42:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26171 for freebsd-current-outgoing; Wed, 21 Oct 1998 07:42:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26164 for ; Wed, 21 Oct 1998 07:42:32 -0700 (PDT) (envelope-from lists@tar.com) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.9.1/8.8.7) with SMTP id JAA20186; Wed, 21 Oct 1998 09:42:02 -0500 (CDT) Message-Id: <199810211442.JAA20186@ns.tar.com> From: "Richard Seaman, Jr." To: "Daniel Eischen" Cc: "current@freebsd.org" Date: Wed, 21 Oct 98 09:42:02 -0500 Reply-To: "Richard Seaman, Jr." X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Another Serious libc_r problem Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Oct 1998 09:18:22 -0400 (EDT), Daniel Eischen wrote: >> The condition can only be signaled when >> the condition spinlock is not held. So... why wouldn't you hold the >> condition spinlock as long as possible (ie. after the mutex unlock) >> and *then* set _thread_kern_in_sched = 1 after all the spinlocks have >> been done? > >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). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message