Hans Petter Selasky <hselasky@c2i.net> writes:

> On Saturday 13 August 2005 21:29, Nathan J. Williams wrote:
> > Hans Petter Selasky <hselasky@c2i.net> writes:
> > > Maybe I am a little too quick to say this, but doesn't the whole USB
> > > system just use splnet/splx to protect data structures? On a
> > > multiprocessor system, isn't things going to crash after a while, hence
> > > more than one CPU can enter into the code that is protected by
> > > splnet/splx ? So actually it is time they implement mutexes in NetBSD
> > > too?
> >
> > NetBSD's SMP kernel is under a big-lock, so this isn't a problem for
> > the time being.
> 
> This almost sounds like the Giant lock on FreeBSD. But then, actually 
> splnet/splx and simple_lock/simple_unlock does not have any effect at all?

Yes, it is like the Giant lock.

splnet/splx are about protecting yourself from interrupts on the same
CPU. On a multiprocessor system, when tring to preserve the integrity
of data used by interrupt code, you have to protect from those, as
well as from activity on other CPUs. There are abstractions that mask
this distinction, but NetBSD doesn't generally use them.

> What happens on NetBSD if a process calls "tsleep()" while holding a 
> simple_lock()? Is there any code to do extra checking like on FreeBSD ?

Deadlock can result. Don't do that. Simple locks are, in fact,
minimally simple (in fact, they're no-ops on single processor
systems), and do not invoke any checking for errors of that nature.

> I've heard that NetBSD is very against mutexes. Is this true? Will NetBSD 
> always use one lock for the whole kernel?

I'm not sure where you've heard this. There are many people who would
like to break down the kernel lock, but it's a big project and
requires a lot of resources.

        - Nathan