David Kanter (dkanter@realworldtech.com) on 5/16/06 wrote:
---------------------------
>AnalGuy (AnalGuy@yahoo.com) on 5/16/06 wrote:
>---------------------------
>>Why are you talking about distributed algorithms, we are not discussing Distributed
>>Systems, we are just discussing Microkernel and Monolothic >kernels.
>
>Well, I think the discussion has a lot to do with the theory behind mono versus
>micro. I'm not an OS developer, but my understanding is that ukernels need to have
>a lot of message passing between different blocks of software, whereas mono kernels
>simply share regions of memory. In many respects, this seems to be similar to shared
>memory versus clustered computing. So distributed algorithms would be useful for ukernels.
>
Sometimes the border is pretty fuzzy. When "message passing" merely consists of passing a pointer to an argument block around between code modules, it doesn't look a lot different from pushing arguments onto a stack and passing a frame pointer around. This is a pretty standard model in graphical window systems, particularly on register-starved machines (like x86) that don't usually pass a lot of parameters in registers. This is also the message passing model used in SVR4 STREAMS and Windows WDM drivers (which are pretty much a ripoff of STREAMS modules, as I recall).

But even within a single machine, the framework for queueing messages and such can get pretty expensive. About 12 years ago I was working on an AppleTalk stack written by Pacer software, implemented as individual STREAMS modules for each protocol. It was a pretty text-book implementation of the STREAMS programming model, and frankly its performance was anemic. I rewrote the DDP/ADSP/ATP stack as a single module, while still exporting the individual protocols' STREAMS entry points (But allowing ATP to call directly into DDP etc rather than going through three layers of STREAMS queues) and got as much as a 5x performance increase (depending on the particular machine), without sacrificing any compatibility or concurrency. Abstraction layers are a convenient mental tool for decomposing problems into manageable chunks, but they should only be a conceptual design tool. They cost too much when carried *literally* into implementation land.

The idea of microkernels is valuable, as a conceptual design perspective. The ability to isolate functionality makes it much easier for you to define it and develop it. But just because you define tightly-demarcated interfaces doesn't mean you should always implement that way. E.g., if you want to operate a cluster, with uniform APIs for invoking local or remote modules transparently: you could use a message-passing API locally, and pass message block pointers around to local modules, or you could use a traditional procedure-call oriented API, and turn argument lists into message blocks for remote modules. Ultimately what you choose for the visible API says nothing about how it must be implemented underneath.

>Again, I'm not an OS developer, so someone correct me if I'm spouting nonsense.