On Wed, Feb 21, 2007 at 09:48:25PM -0800, Bill Studenmund wrote:

quoted text
> On Wed, Feb 21, 2007 at 05:57:41PM -0800, jonathan@dsg.stanford.edu wrote:
> > 
> > In message <20070221234224.GF26468@netbsd.org>,
> > Bill Studenmund writes:
> > 
> > >On Wed, Feb 21, 2007 at 10:51:03PM +0000, Andrew Doran wrote:
> > 
> > >> What I want to do will on x86 add 29 arithmetic instructions to the
> > >> interrupt path (as of now). That's means in the common, non blocking case,
> > >> it's ~free. I'd be pretty bummed if we undo some of that and the reasoning
> > >> for doing so is to make the system a better fit for ~20 year old systems.
> > 
> > Andrew, just what will trigger the blocking (expensive) case?
> > And how  expensive is it?
> 
> I'm not Andy, but as I understand it (and I mention this so I'll be 
> corrected if I'm wrong), the blocking case would be where another CPU 
> holds the mutex you need to acess the hardware. i.e. CPU 3 is configuring 
> a piece of hardware then CPU 2 receives an interrupt from that device.

In that case, CPU2 would busy-wait until it gets the mutex. Blocking
unconditionally would be expensive. In order to be able to release a mutex
without using atomic instructions, we actually can't easily block while a
running LWP holds it. They block in two cases:

- the owner is not running on a CPU anywhere in the system
- the owner is spinning on the kernel_lock; we yield to prevent deadlock

In most cases blocking should be the exception to the rule, but there are
situations where that kind of approach would kill us with context switching,
so in the interim we still need to ability to do:

	s = splfoo();
	mutex_enter(&foo_mutex);
	... do something ...
	mutex_exit(&foo_mutex);
	splx(s);

Longer term we need to deal with those kinds of concurrency problems on a
case-by-case basis.

The reader / writer locks always use blocking to synchronize, so they're not
really useful for synchronization from an interrupt handler. At a minimum,
you don't want to try and grab a write hold on the lock from an ISR; there
could be lots of readers to drain out before it's acquired.

Andrew