From owner-cvs-src@FreeBSD.ORG Mon Nov 8 22:33:41 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACD016A4CE; Mon, 8 Nov 2004 22:33:41 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36BEC43D3F; Mon, 8 Nov 2004 22:33:41 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id iA8MXekk030232; Mon, 8 Nov 2004 17:33:40 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id iA8MXeMK030231; Mon, 8 Nov 2004 17:33:40 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 8 Nov 2004 17:33:39 -0500 From: David Schultz To: John Baldwin Message-ID: <20041108223339.GA29876@VARK.MIT.EDU> Mail-Followup-To: John Baldwin , Alfred Perlstein , Alan Cox , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200410311932.i9VJWvmo058193@repoman.freebsd.org> <200411011441.33067.jhb@FreeBSD.org> <20041106062955.GA1986@VARK.MIT.EDU> <200411081311.42201.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411081311.42201.jhb@FreeBSD.org> cc: Alan Cox cc: cvs-src@FreeBSD.ORG cc: Alfred Perlstein cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 22:33:41 -0000 On Mon, Nov 08, 2004, John Baldwin wrote: > > The mutex associated with the condition variable will be held on > > entry to both cv_wait() and cv_signal(), so why is the sleepqueue > > locked in the no waiters case? > > It is no longer required to hold the mutex over cv_wait() and cv_signal(). I > intentionally changed that so that you can do: > > lock() > blah() > unlock() > cv_signal() > > and reduce the number of context switches if you preempt in cv_signal(). Hmm...I agree with Alfred that allowing this is a bad idea. By permitting this, you're adding two additional mutex operations to the critical path in order to avoid an inefficiency that will almost never occur. Suppose that the cv_signal() is done immediately *before* the unlock operation. The odds that the signalling thread is preempted in a the few cycles between the cv_signal() and the unlock are close to nil. Furthermore, on a multiprocessor, it will take longer for another processor to schedule one of the waiters than it will for the signalling processor to release the lock. The original formulation of this kind of condition variable was in Mesa[1], which requires the lock to be held during cv_signal() specifically for efficiency.[2] Solaris also requires the mutex to be held across cv_signal(). PThreads is the only API I know of to have it the other way around. [1] http://research.microsoft.com/Lampson/23-ProcessesInMesa/WebPage.html [2] It supported a second, less efficient type of CV that would allow device microcode to signal device drivers without holding the mutex, but all other CVs required the mutex to be held when the CV was signalled. But this second kind of CV is irrelevant today.