Erik Verbruggen <[EMAIL PROTECTED]> writes:

> The important things a microkernel does, is MMU handling (memory
> management) and message passing (IIRC).

Perhaps one should add scheduling to that list as well. And perhaps
also low-level i/o arbitration. 

> As communication between
> seperate user-space processes is done by message-passing, it's one of
> the places where context-switches take place.
> 
> Now, can't this be done by setting up a direct communication channel
> between two userspace processes? With a semaphore you can check on
> incoming messages, etc. This way you only need to do a context-switch if
> you ask the kernel to set up a direct message-channel.

Then the communicationg processes need to share some or all memory.
For an example, look at AmigaOS, which was amazingly fast, and was
based on message passing and shared memory. Of course, then you lose
some or all of the protection between processes. Sometimes that may be
ok (say, if all involved processes run with the same privileges), in
other cases it is terrible for security. And even if we leave security
issues aside, strong protection between processes should make the
system more robust. 

> Also, for asynchonous message passing, a complete context switch is not
> needed -- you deliver the message by putting it in the queue of the
> receiving process and go back to the original program. In this case
> there is no loading of the receiving process state.

But the sending process must be allowed to mess with the other
process's queue, and can probably screw it up. And you still have some
overhead with syncronizing access to the shared memory (on the Amiga
case, you temporarily disabled context switching by calling Forbid().
There were things like semaphores as well, but they was not used for
simple message delivery).

In essence, we're comparing inter-process communication with
inter-thread communication, where a process is defined as something
that does not share any (writable) memory with random other processes.

There are also some other tricks to reduce the cost of context
switches. Does anybody know how Solaris "doors" works? I have been
told that they enable rpc-calls where the calling thread is somehow
executing in the context of the called process for the duration of a
call. Although that sounds somewhat strange to me.

/Niels

Reply via email to