Subject: Re: SMP/flogging a dead horse
To: Michael Graff <explorer@flame.org>
From: Todd Whitesel <toddpw@best.com>
List: current-users
Date: 08/31/1998 03:33:51
> > Nevertheless, I've seen attempts to patch single-threaded code into
> > multi-processor code go into the weeds a hell of a lot faster and a hell of
> > a lot more frequently than attempts to engineer proper multithreaded data
> > structures from the start.  The difference between a single-threaded system
> > and a multi-processor system is *not* just missing code.

I agree that the threat exists. However if we managed to push through a
rewrite of the VM system, then I think we can manage to push through a
rewrite of the MP system later when it becomes clear how the darn thing
should have worked.

> IMHO, supporting MP first with plans to move to SMP later is the
> right thing to do.  At least we'd have a few more users, and probably
> more developers.

Certainly more _effective_ developers. Anything that speeds up builds is
good, because it encourages people to experiment and investigate more, and
to spend less time racking their brains second-guessing code they don't grok.

> I'm all for the perfection model, so long as it doesn't keep netbsd
> from ever growing.

I would argue that unless we have someone who is very certain of the final
code architecture, we should not even _attempt_ to get it completely right
the first time.

Better to do a Q&D job that everyone agrees should be overhauled later, so
you don't succumb to the paralysis of analysis without something to show
for it. Besides, you can use the crappy MP solution to compile the good MP
solution much faster, leaving you more time with which to get it done right.

Todd Whitesel
toddpw @ best.com