cvs commit: src/sys/vm vm_zeroidle.c
jhb at FreeBSD.org
Thu Nov 11 08:13:36 PST 2004
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
> The original formulation of this kind of condition variable was in
> Mesa, which requires the lock to be held during cv_signal()
> specifically for efficiency. 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.
>  http://research.microsoft.com/Lampson/23-ProcessesInMesa/WebPage.html
>  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
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the cvs-src