V Messaging Semantics
A key concept to almost all microkernels is breaking down a single large kernel into a set of communicating servers. Instead of having a single large program in control of the entire hardware side of the computer system, these sorts of duties are handed out to smaller programs that are given rights to control different parts of the machine. For instance, a particular server might be given control of the networking hardware, while another has the task of managing the hard drives. Another server would handle the file system, calling both of these lower-level servers. User applications ask for services by sending messages to these servers, using some form of inter-process communications (IPC), as opposed to asking the kernel to do this work via a syscall or trap.
Under V the IPC system appears to be conceptually modeled on remote procedure calls (RPC) from the client application's perspective. The client application imported a interface definition file containing information about the calls supported by the kernel, or other applications, and then used this definition to package up requests. When called, the kernel would immediately take over, examine the results, and pass the information off to the right handler, potentially within the kernel itself. Any results were then handed back through the kernel to the client.
In general terms, the operation of the system as it appears to the client application is very similar to working with a normal monolithic kernel. Although the results passed back might come from a third party handler, this was essentially invisible to the client. Servers handling these requests operated in a similar fashion to the clients, opening connections with the kernel to pass data. However, servers generally spawned new threads as required to handle longer-lasting requests. When these were handled and the responses posted, the thread could be de-allocated and the servers could go into a "receive mode" awaiting further requests.
In contrast, most microkernel systems are based on a model of asynchronous communications, as opposed to synchronous procedure calls. The canonical microkernel system, Mach, modeled messages as I/O, which has several important side-effects. Primary among these is that the normal task schedulers under Unix-like systems will normally block a client that is waiting on an I/O request, so in this way the actions of pausing and restarting applications waiting on messages was already built-in to the underlying system. The downside to this approach is that the scheduler is fairly "heavyweight", and calling it was a serious performance bottleneck and led to extensive development efforts to improve its performance. Under the V-System model the message passing overhead is reduced because the process scheduler does not have to be consulted, there is no question as to who should next be run – it's the server being called. The downside to the V approach is that it requires more work on the server side if the response may take some time to process.
Read more about this topic: Vanguard (microkernel)