Date: Mon, 8 Nov 2004 16:49:24 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: jhb@FreeBSD.org Cc: das@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c Message-ID: <200411090049.iA90nOmC055719@gw.catspoiler.org> In-Reply-To: <200411081311.42201.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411090049.iA90nOmC055719>