Interprocess Communication

Inter-process communication (IPC) is a set of techniques for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC techniques are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.
There are several reasons for providing an environment that allows process cooperation:
Information sharing
Computation speedup
Modularity
Convenience
IPC may also be referred to as inter-thread communication and inter-application communication.
IPC, on par with the address space concept, is the foundation for address space independence/isolation

Direct Communication

Processes must name each other explicitly:

send (P, message) – send a message to process P receive(Q, message) – receive a message from process Q Properties of communication link-Links are established automatically A link is associated with exactly one pair of communicating processes-Between each pair there exists exactly one link-The link may be unidirectional, but is usually bi-directional

Indirect Communication

•messages sent to and received from mailboxes (or ports)
–mailboxes can be viewed as objects into which messages placed by processes and from which messages can be removed by other processes
–each mailbox has a unique ID
–two processes can communicate only if they have a shared mailbox

Synchronization

"Synchrony" redirects here. For linguistic synchrony, see Synchronic analysis (linguistics). For the X-Files episode, see Synchrony (The X-Files).
For similarly named concepts, see Synchronicity (disambiguation).
Not to be confused with data synchronization.

Synchronization or synchronisation is timekeeping which requires the coordination of events to operate a system in unison. The familiar conductor of an orchestra serves to keep the orchestra in time. Systems operating with all their parts in synchrony are said to be synchronous or in sync. Some systems may be only approximately synchronized, or plesiochronous. For some applications relative offsets between events need to be determined, for others only the order of the event is important.

• Blocking Send

A blocking send can be used with a non-blocking receive, and vice-versa, e.g.,

• Nonblocking Send

can use any mode - synchronous, buffered, standard or ready

returns as soon as possible, that is, as soon as it has posted the send. The buffer might not be free for reuse.

-Non-blocking send has the sender send the message and continue.

• Blocking Receive

Blocking receive has the receiver block until a message is available

• Nonblocking Receive

Non-blocking receive has the receiver receive a valid message or null.

Buffering

•the number of messages that can reside in a link temporarily
–Zero capacity - queue length 0
»sender must wait until receiver ready to take the message
–Bounded capacity - finite length queue
»messages can be queued as long as queue not full
»otherwise sender will have to wait
–Unbounded capacity
»any number of messages can be queued - in virtual space?
»sender never delayed

• Zero Capacity

0 messagesSender must wait for receiver (rendezvous)

• Bounded capacity

finite length of n messagesSender must wait if link full.

• Unbounded Capacity

infinite length Sender never waits

Procedure-Consumer Example

• Procedure

a person who produces.
»get a message block from mayproduce
»put data item in block
»send message to mayconsume

• Consumer

a person or thing that consumes.
»get a message from mayconsume
»consume data in block
»return empty message block to mayproduce mailbox