cvs commit: src/sys/vm vm_zeroidle.c

[Don Lewis]

On  8 Nov, John Baldwin wrote:

> 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().

cv_wait() unlocks and relocks the mutex, so it is necessary to hold the
mutex before calling cv_wait().  It is also likely that the mutex would
have to be held to avoid having the condition being waited on going away
after the mutex was dropped and before the cv_wait() call, which could
cause the thread to miss a wakeup and sleep forever.

If the caller holds the mutex across the call to cv_signal(), the caller
may be able to avoid calls to cv_signal() if it knows that there are no
waiters.  In most cases, the caller will want to release the mutex when
it calls cv_signal().  A version of cv_signal() that releases the mutex
after calling sleepq_lock() and before calling sleepq_signal() or
sleepq_release() would allow unnecessary calls to sleepq_signal() to be
optimized out, while avoiding the extra context switches that could be
caused by holding the mutex until after cv_signal().