From: mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 20:26:47 GMT
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Originator: osr@ftp

ast@cs.vu.nl (Andy Tanenbaum) writes:
>Gee, reading this newsgroup is more fun than whacking a hornet's nest with
>a baseball bat.

	That *WAS* what you were trying to do, wasn't it?

>   1. Microkernels are the way to go.
>         For the system to work, the kernel has to be reliable.  Putting the
>      file system and other user services inside makes it harder to get right
>      and less flexible.  The performance loss is (guess) less than a factor
>      of two.

	A factor of two is not acceptable in anything other than an academic
research environment. Here in the industry, our livelihoods are often at
stake when we try to benchmark our XYZ against our competitor's XYZ and see
which is faster. Some theoretical statement that microkernels are more
elegant is useless.

	Reliability is another issue. Certainly a well designed microkernel
architecture can be more reliable than a monolithic kernel that's not very
well designed, but this is a meaningless argument. In the long run, the
factor that most dramatically affects the reliability of your system is
the skill of your programmers, the skill of your systems designers, the
adherence of them to the design and clean interfaces, and testing, testing,
testing. The ability to run the file system of a microkernel as a test
filesystem is no different from the (desireable) ability to put the
monolithic kernel's filesystem into a test rack outside the kernel.

	In short, you seem to be asserting that good design and implementation
is inherent in microkernels. This confuses me. I'm sure we could try an
"obfuscated microkernel contest" if you need convincing.

>   2. Synchronous (blocking) communication is easier to use than asynchronous.
>         Starting a send, then going off to do something, followed by getting
>      an interrupt when the send is done is a nightmare to program.  If you
>      must do something while waiting for the reply, put that code in another
>      (synchronous) thread.  The biggest problem in the computer industry is
>      not slow machines, but hairy, unreliable software.  Using asynchronous
>      communication just makes the problem worse.

	This I will grant you, but it's a meaningless statement because
it's divorced from context. There are cases where you may NEED asynchronous
communication, and it's the model to use. There are cases where it's
so natural to do something asynchronously that trying to do it otherwise
will make your software less reliable. And vice versa.

	Since we're on the topic in general of "what we've learned in the
last N years" I'm rather surprised that anyone is trying to make such
general statements. One thing I'd have HOPED we'd learn in the last
N years would be that you use the tool and methods that best suits the
job at hand. If you're trying to model an asynchronous process, it
seems foolish to go for political correctness and hammer your model
until it looks synchronous.

>   3. RPC is a good idea to base your system on.

	RPC is - what - an abstraction of writing a procedure that appears
to be local, but is or can be remote. So, what's the abstraction here? A
function call? Yes, I agree. We have all learned that function calls are
a good abstraction in programming, and let you write modular code, etc.

	RPC is not an abstraction in and of itself, it's a different use
of the procedure call abstraction - it's making what appears to be a
"normal" local procedure call nonlocal.

	Aside from that philosophical nit, I agree that RPC is very useful
for developing distributed synchronous applications. I think Pike's point
was that you still need to be careful as far as restricting the RPCs that
can be used and generalizing them. I fail to see a huge difference (other
than in the latency issues) between RPC and LPC. You have the same problems
of making sure interfaces don't change under you, making sure that the
called code is reliable and doesn't get broken behind your application's
back, etc. The issues are complicated by heterogenous systems, but I see
it as just an extension of the problems associated with using libc.a, or
a shareable libc.a

>   4. Atomic group communication (broadcast or multicast) is highly useful.

	If you need it, yes, it's very useful.

>   5. Distributed shared memory in one form or another is a convenient model.
>         Even better than communicating synchronously is not communicating
>      explicitly at all.  Just let the programmer think there is shared
>      memory, be it page-based, object-based, or other.  Let the system
>      do the work.  There is an obvious analogy with virtual memory.

	Sure, it's a convenient model, and like many convenient models,
you can sweep a lot of stuff under the carpet of convenience. You can
use DSM to "distribute" an application with only a little bit of
apparent work, and you can totally ignore the fact that DSM may want
to affect your design. Obviously, if I have existing code that does
walks of a page of memory shared between 60 machines and starts
setting and unsetting bits, the performance isn't going to be quite
like the local case. It's an easier programming model, but the
software may suck rocks.

>As you can see, all of my points relate to one theme: making it easier to
>build and use distributed systems. I think this is the real issue of the coming
>decade, not squeezing another factor of two out of the hardware.  Improvements
>in technology will take care of that.

	Aaaaah, it finally comes. "Improvements in technology will take
care of that" - as I mentioned before, sometimes that doesn't work for
people who are fighting to win business that depends on performance.
I'd be thrilled to death if all of DEC's competitors started writing
code that was a factor of two slower than ours - my job would be a lot
easier.

	It's tempting to make a remark like "that's fine if you're
doing research", but that wouldn't be fair to Pike and all, who have
not only been doing thoughtful exploration of some approaches to
distributed systems, but have been careful to keep things small and
efficient the while.

	By the time your hardware realizes its factor of two improvement,
you'll generally find that X-windows and GNU emacs have already used it.

mjr.


----- End Included Message -----