cvs commit: src/sys/vm vm_zeroidle.c

[John Baldwin]

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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org