On Tue, 20 Mar 2001, Greywolf wrote:

> I've heard rumours flying about that NetBSD 2.0 (somewhere down the road)
> will be a BigLock [TM] MP thing.
> 
> I was seriously hoping that BigLock would never see an official release.
> It just seems the wrong thing to do.  Yes, it's a stepping stone, and should
> probably be made available in a -current or -mp branch, but it just seemed
> to me that we could beat the game by being the first OS to skip the BigLock
> scheme on a release and just go *wham* "Here we are - granular-lock SMP".
> 
> ...or is that entirely unreasonable (in which case I apologise for
> my unreasoning)?

Given that we don't have a gross of programmers which can dive into the
kernel and work out the threading problems, we will have to live with
BigLock. While not as nice as granular-lock SMP, it is an improvement over
what we have now. Yes, threads/processes needing the kernel have to
wait. But if you have a compute-intensive program, where most of your
threads will not be in the kernel, then BigLock sure is a win over what we
have now. :-)

Also, right now we have the ability (in -current) to mark syscalls as
being MPSAFE. We even have a syscall marked with it (getpid()). So as we
make different parts of the kernel MP-safe, the assosciated syscalls will
not need the biglock. Note: I don't think we have the code yet to not grab
the biglock, but we're moving there. :-)

I think the big reason to have BigLock is that we've waited long enough.
If we wait until it's perfect, it'll never happen (as more requirements
will have come along in the mean time).

Take care,

Bill