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
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
> 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
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