Operating Systems

Process Management – Part 3

Message Passing Issues


Processes wanting to communicate with one another can use either direct or indirect communication.

In direct communication,

  • A link is automatically established between two processes wishing to communicate. They both need to know only each other’s identity to communicate.
  • A link is associated with exactly two processes.
  • Between each processes pair, exactly one link exists.

In symmetric addressing, both the sender and receiver name each other. In asymmetric addressing, only the sender needs to identify the recipient, and the recipient doesn’t need to define anything.

The disadvantage with both the schemes described above are that they are ‘hard-coded techniques’, which means that if the identifier of the process is to be changed, all references to the old identifier must be found and changed to the new identifier.

This is the reason that indirect communication is more desirable. Messages are sent to and received from abstract ‘mailboxes’ or ‘ports’. Each mailbox has a unique identifier (In POSIX message queues, a unique integer value is used). A process can communicate with a number of different mailboxes, and two processes that share a mailbox can communicate with each other.

In indirect communication,

  • A link is established between two processes if both share a mailbox.
  • A link (corresponding to one mailbox) may be shared by more than two processes.
  • Between a pair of communicating processes, there might be a number of different links (or different shared mailboxes).

If three processes share the same mailbox, and one of them sends a message to that mailbox, and the other two processes execute the receive() operation to read the messages, there might be a problem as to which process will get the message. Here, we need to consider the various restrictions that the developer (or the OS) can impose on mailboxes:

  • Allow a mailbox to be associated with only two processes at most.
  • Allow only one processes to execute receive() at a time.
  • Allow the system to decide which process will receive the message – either arbitrarily, or through an algorithm such as ’round robin’.

A mailbox may also either be owned by the process or by the operating system.

If the mailbox is owned by a process, any process can send messages to that mailbox, but only the owner process can receive them. But if the owner process terminates, the mailbox ceases to exist, and messages can no longer be sent to it.

If the mailbox is owned by the OS, it is independent and isn’t attached to any particular process. The OS must provide the mechanisms for a process to create and delete a mailbox, and to send and receive messages through mailboxes. The process that creates a mailbox is its sole inital owner and receiver. These privileges might be passed on to other processes, which could result in mailboxes having multiple receivers.


Message passing may be either blocking or nonblocking (synchronous and asynchronous):

  • Blocking send – Sending process blocked until message is received by the receiving process or by the mailbox.
  • Nonblocking send – Sending process sends message and resumes operation.
  • Blocking receive – Receiver process blocked till a message is available.
  • Nonblocking receive – Receiver retrieves either a valid message or a null.

Different combinations of these are possible. When both send() and receive() are blocking, we have a rendezvous between the sender and the receiver. This offers a trivial solution to the producer-consumer problem.


Whether using the direct or indirect communication, messages reside in a temporary queue. Such queues are implemented in three ways:

  • Zero capacity – It cannot have any messages waiting in it, so the sender must basically block till the message is received by the recipient.
  • Bounded capacity – These have finite capacity. If the queue is not full, the sender can place the message in the queue and continue operating. Else, the sender has to block until space is available in the queue.
  • Unbounded capacity – The queue has (potentially) infinite capacity. Hence the sender never has to block.

Systems with zero capacity are known as message systems with no buffering, and the others are known as systems with automatic buffering.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s