Date: Sun, 03 Jul 2005 01:16:49 -0000 From: John Baldwin <jhb@FreeBSD.org> To: David Schultz <das@FreeBSD.org> Cc: Alan Cox <alc@FreeBSD.org>, cvs-src@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c Message-ID: <200411100919.01103.jhb@FreeBSD.org> In-Reply-To: <20041108223339.GA29876@VARK.MIT.EDU> References: <200410311932.i9VJWvmo058193@repoman.freebsd.org> <200411081311.42201.jhb@FreeBSD.org> <20041108223339.GA29876@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 08 November 2004 05:33 pm, David Schultz wrote: > 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. Actually, it would always occur on a UP system if you preempt in the signal/broadcast. FWIW, I've specifically had other people ask for this "feature". Note that this also now allows you to do things like 'cv_signal()' from a fast interrupt handler if needbe. > 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. Since setrunqueue() itself can preempt now, the odds are higher than you might think. > 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. Well, it is easy enough to back out if the differering opinions on the subject can reach a consensus. There was a discussion on smp@ a while back in favor of allowing cv_signal/broadcast to not require the mutex to be held there earlier. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411100919.01103.jhb>