Date: Thu, 11 Nov 2004 16:32:24 -0500 From: David Schultz <das@FreeBSD.ORG> To: John Baldwin <jhb@FreeBSD.ORG> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c Message-ID: <20041111213224.GA5239@VARK.MIT.EDU> In-Reply-To: <200411100919.01103.jhb@FreeBSD.org> References: <200410311932.i9VJWvmo058193@repoman.freebsd.org> <200411081311.42201.jhb@FreeBSD.org> <20041108223339.GA29876@VARK.MIT.EDU> <200411100919.01103.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 10, 2004, John Baldwin wrote: > > 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. There's always the possibility of providing two types of condition variables as in Mesa, one of which is capable of performing a ``naked notify'', as Lampson calls it. > > 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. Yeah, if there is an explicit yield, that could be a problem. Priority propagation for CVs might help, but the right answer to that problem is probably to have a way to make a thread runnable without yielding. > 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. I have no intent of going on a war path against the current semantics (particularly given how little time I have for kernel hacking these days.) But it doesn't seem to me that the choice that was made is the correct one. Synchronization primitives should be lightweight enough that people don't need to invent ad hoc ones of their own to avoid ``expensive cv_wakeup() calls'' and so forth.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041111213224.GA5239>