From owner-freebsd-bugs Sat Oct 24 05:00:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA07231 for freebsd-bugs-outgoing; Sat, 24 Oct 1998 05:00:06 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA07217 for ; Sat, 24 Oct 1998 05:00:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA23686; Sat, 24 Oct 1998 05:00:00 -0700 (PDT) Date: Sat, 24 Oct 1998 05:00:00 -0700 (PDT) Message-Id: <199810241200.FAA23686@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Dmitrij Tejblum Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Reply-To: Dmitrij Tejblum Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8375; it has been noted by GNATS. From: Dmitrij Tejblum To: Daniel Eischen Cc: freebsd-gnats-submit@FreeBSD.ORG, jb@FreeBSD.ORG Subject: Re: kern/8375: pthread_cond_wait() spins the CPU Date: Sat, 24 Oct 1998 15:49:13 +0400 Daniel Eischen wrote: > I don't see any other way of making pthread_cond_[timed]wait > bulletproof without disabling scheduling. You shouldn't > allow nesting of spinlocks being taken if there is a chance > of creating a deadlock. Let's assume that you do not nest > the condition variable and mutex spinlocks. Why? Frankly, I don't see any harm here. Sure, it is not safe to _SPINUNLOCK the condition lock before pthread_mutex_unlock. So it has to be done in other way around. > You need to disable thread scheduling. The way I've done it, > it doesn't hurt anything and will prevent needless thrashing > of threads. You want mutex_lock and cond_wait and friends > to be atomic and this does that without needless thrashing. I don't think the "trashing" is dangerous. Spinlocks are held due to very short period of time (this is the main assumption in their design and implementation). The chances that a thread holding a spinlock will be preempted are very low. Even if the thread will be preempted, the chances that another thread will try to lock the same spinlock are low. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message