Operating System

Interprocess Communication

Direct communication:The sender and receiver can communicate in either ofthe following forms:• synchronous—involved processes synchronize at everymessage. Both send and receive are blockingoperations. This form is also known as a rendezvous.• asynchronous—the send operation is almost alwaysnon-blocking. The receive operation, however, can haveblocking (waiting) or non-blocking (polling) variants. Processes must explicitly name the receiver or senderof a message (symmetric addressing).– send (P, message). Send message to process P.– receive (Q, message). Receive message from Q.In a client-server system, the server does not have toknow the name of a specific client in order to receivea message. In this case, a variant of the receiveoperation can be used (asymmetric addressing).– listen (ID, message). Receive a pending (posted)message from any process; when a message arrives,ID is set to the name of the sender. In this form of communication the interconnectionbetween the sender and receiver has the followingcharacteristics:• A link is established automatically, but the processesneed to know each other’s identity.• A unique link is associated with the two processes.• Each pair of processes has only one link between them.• The link is usually bi-directional, but it can be uni-directional.

Indirect communicationIn case of indirect communication, messages are sentto mailboxes, which are special repositories. Amessage can then be retrieved from this repository.– send (A, message). Send a message to mailbox A.– receive (A, message). Receive a message frommailbox A.This form of communication decouples the senderand receiver, thus allowing greater flexibility.Generally, a mailbox is associated with many sendersand receivers. In some systems, only one receiver is(statically) associated with a particular mailbox; sucha mailbox is often called a port.
A process that creates a mailbox is the owner
(sender). Mailboxes are usually managed by the
system.
The interconnection between the sender and receiver
has the following characteristics:
• A link is established between two processes only if they
“ share” a mailbox.
• A link may be associated with more than two processes.
• Communicating processes may have different links
between them, each corresponding to one mailbox.
• The link is usually bi-directional, but it can be uni-
directional.



Synchronization
•  Message passing may be either blocking or non-
blocking
•  Blocking is considered synchronous
–  Blocking send has the sender block until the message is
received
–  Blocking receive has the receiver block until a message
is available
•  Non-blocking is considered asynchronous
–  Non-blocking send has the sender send the message
and continue
–  Non-blocking receive has the receiver receive a valid
message or null


Buffering
•  Queue of messages attached to the link;
implemented in one of three ways

1. Zero capacity – 0 messages
Sender must wait for receiver (rendezvous)
2. Bounded capacity – finite length of n message
Sender must wait if link full
3. Unbounded capacity – infinite length
Sender never waits


Producer-Consumer Example

The Producer and Consumer examples share data through a common CubbyHole object. Although, ideally, Consumer will get each value produced once and only once, neither Producer nor Consumer makes any effort whatsoever to ensure that this happens. The synchronization between these two threads occurs at a lower level within the get and put methods of the CubbyHole object. Assume for a moment, however, that the two threads make no arrangements for synchronization; let's discuss the potential problems that might arise from this.

The producer-consumer problem illustrates the need for synchronization in systems where many processes share a resource. In the problem, two processes share a fixed-size buffer. One process produces information and puts it in the buffer, while the other process consumes information from the buffer. These processes do not take turns accessing the buffer, they both work concurrently. Herein lies the problem.


The consumer checks to see if the buffer is empty. If so, the consumer will put itself to sleep until the producer wakes it up. A "wakeup" will occur if the producer finds the buffer empty after it puts an item into the buffer. (2) Then, the consumer will remove a widget from the buffer. The consumer will never try to remove a widget from an empty buffer because it will not wake up until the buffer is full.(3) If the buffer was full before it removed the widget, the consumer will wake the producer. (4) Finally, the consumer will consume the widget. As was the case with the producer, an interrupt could occur between any of these steps, allowing the producer to run.