| Prev | Table of Contents | Next |
Processes in an Operating System are not isolated entities. There are many situations in which some kind of communication between two processes is desired. When reading a file, for example, a program needs some way of telling the process that manages the filesystem to open that file. In the shell, is possible to use a pipe to connect the output and the input of two commands. There are thousands of trivial examples like this, that illustrate tha communication is quite an inportant issue; then is a critical design aspect in Operating Systems to which we must pay close atention.
One quite elegant way of communicating processes is the exchanging of messages. There are mainly two operations that can be conceibed over messages : the sending and the reception of messages. Therefore we could think about two primitives for message passing :
send( destination, &message );and of course
receive( source, &message );
but is better to thought in a more conceptually ( and general ) way :
this reminds a little to object-oriented programming, as thought in smalltalk, in where we communicate with object by sending them messages. Usually, when a process is waiting a message it gets blocked.
The message passing bring us some interesting design problems and aspects. For example, is needed a means with which to name processes, so when sending a message, the destinatary of this message could be unambiguously referred. This is a problem of identification close atention must be paid of how some kind of IPC solve this problem.
Another problem comes from the fact that the message could get lost before received ( for example, if the remitent and destinatary of the message are in different machines connected by a network ). Some kind of confirmation is needed; would be very nice to know is our message was received, and in negative case, why it didn't. In this last case, what would the remitent of the message do ?. An important aspect of the confirmation problem is that of the semantic in case of fail : in some system the remitent would quit, while in other it would try again.
A situation that could happen is that some client process sent some critical information in a message to a server process, but the trusted server process was replaced by an impostor; some kind of legitimation is needed, in order that the message passing mechanisms could be trusted.
todo: message passing schemes : rendezvous, mailboxes, pipes ...