Inter-Process Communication

PROCESS

A process can be of two types:

1. Independent process.

2. Co-operating process.

An independent process is not affected by the execution of other processes while a co-operating process can be affected by other executing processes. Though one can think that those processes, which are running independently, will execute very efficiently, in reality, there are many situations when co-operative nature can be utilized for increasing computational speed, convenience, and modularity. That’s where inter-Process Communication jumps in.

Inter-Process Communication

Inter-process communication (IPC) refers specifically to the mechanisms an operating system provides to allow the processes to manage shared data. In other words, Inter-process communication (IPC) is a mechanism that allows the exchange of data between processes. This communication could involve a process letting another process know that some event has occurred or the transferring of data from one process to another.

In general IPC can take one of two forms:

1. Asynchronous: with asynchronous IPC the sender does not wait for the receiver to receive the message. The send function or method returns immediately, and then sometime later the receiver receives the message. If the message requires a response from the receiver, then the message may supply details of how the receiver can send a reply to the sender.

2. Synchronous: with synchronous IPC the send and receive are synchronized, and often from the receiver’s perspective it appears like a normal method or function call, with any response from the receiver passed to the sender as the return value from the send function or method. With synchronous IPC, if the receiver is slow responding to the message the sender will block until the receiver responds. This is often undesirable in user interface components.

Approaches to IPC

Different approaches to IPC have been tailored to different software requirements, such as performance, modularity, and system circumstances such as network bandwidth and latency.

1. Pipe

2. Socket

3. File

4. Signal

5. Shared Memory

6. Message Queue

Pipe

Pipes were introduced in the UNIX operating system. In this mechanism, the data flow is unidirectional. A pipe can be imagined as a hose pipe in which the data enters through one end and flows out from the other end. A pipe is generally created by invoking the pipe system call, which in turn generates a pair of file descriptors. Descriptors are usually created to point to a pipe node.

One of the main features of pipes is that the data flowing through a pipe is transient, which means data can be read from the read descriptor only once. If the data is written into the write descriptor, the data can be read only in the order in which the data was written. Two pipes can be used to create a two-way data channel between two processes. This uses standard input and output methods. Pipes are used in all POSIX systems as well as Windows operating systems.

Socket

The socket is the endpoint for sending or receiving data in a network. This is true for data sent between processes on the same computer or data sent between different computers on the same network. Most of the operating systems use sockets for inter-process communication.

File

A file is a data record that may be stored on a disk or acquired on demand by a file server. Multiple processes can access a file as required. All operating systems use files for data storage.

Signal

Signals are useful in inter-process communication in a limited way. They are system messages that are sent from one process to another. Normally, signals are not used to transfer data but are used for remote commands between processes.

Shared Memory

Shared memory is the memory that can be simultaneously accessed by multiple processes. This is done so that the processes can communicate with each other. Communication between processes using shared memory requires processes to share some variable, and it completely depends on how the programmer will implement it.

One way of communication using shared memory can be imagined like this: Suppose process1 and process2 are executing simultaneously, and they share some resources or use some information from another process. Process1 generates information about certain computations or resources being used and keeps it as a record in shared memory. When process2 needs to use the shared information, it will check in the record stored in shared memory and take note of the information generated by process1 and act accordingly.

Processes can use shared memory for extracting information as a record from another process as well as for delivering any specific information to other processes. All POSIX systems, as well as Windows operating systems use shared memory.

Message Queue

Multiple processes can read and write data to the message queue without being connected to each other. Messages are stored in the queue until their recipient retrieves them. Message queues are quite useful for inter-process communication and are used by most operating systems. All processes can exchange information through access to a common system message queue. The sending process places a message (via some (OS) message-passing module) onto a queue which can be read by another process. Each message is given an identification or type so that processes can select the appropriate message. Process must share a common key in order to gain access to the queue in the first place.

Implementation in System V (UNIX)

Linux supports three types of inter-process communication mechanisms which first appeared in Unix System V (1983). These are message queues, semaphores and shared memory. These System V IPC mechanisms all share common authentication methods. Processes may access these resources only by passing a unique reference identifier to the kernel via system calls. Access to these System V IPC objects is checked using access permissions, much like accesses to files are checked. The access rights to the System V IPC object are set by the creator of the object via system calls. The object’s reference identifier is used by each mechanism as an index into a table of resources. It is not a straight forward index but requires some manipulation to generate the index.

All Linux data structures representing System V IPC objects in the system include an “ipc_perm” structure which contains the owner and creator processes user and group identifiers. the access mode for this object (owner, group and other) and the IPC object’s key. The key is used as a way of locating the System V IPC object’s reference identifier. Two sets of keys are supported: public and private. If the key is public then any process in the system, subject to rights checking, can find the reference identifier for the System V IPC object. System V IPC objects can never be referenced with a key, only by their reference identifier.

Semaphores

Semaphores are a programming construct designed by E. W. Dijkstra in the late 1960s. Dijkstra’s model was the operation of railroads: In the computer version, a semaphore appears to be a simple integer. A process (or a thread) waits for permission to proceed by waiting for the integer to become 0. The signal if it proceeds signals that this by performing incrementing the integer by 1. When it is finished, the process changes the semaphore’s value by subtracting one from it.

Advantages

· It helps to speedup modularity

· Computational

· Privilege separation

· Convenience

· Helps operating system to communicate with each other and synchronize their actions

Potential Inter-process Communication Problems

Starvation

A starvation condition can occur when multiple processes or threads compete for access to a shared resource. One process may monopolies the resource while others are denied access.

Deadlock

A deadlock condition can occur when two processes need multiple shared resources at the same time in order to continue.

Data Inconsistency

When shared resources are modified at the same time by multiple resources, data errors or inconsistencies may occur. Sections of a program that might cause these problems are called critical sections. Failure to coordinate access to a critical section is called a race condition because success or failure depends on the ability of one process to exit the critical section before another process enters the critical section. It is often the case that two processes are seldom in the critical section at the same time; but when there is overlap in accessing the critical section, the result is a disaster.

Producer-Consumer problem

The Producer-Consumer problem is a classical multi-process synchronization problem, that is we are trying to achieve synchronization between more than one process. There is one Producer in the producer-consumer problem, Producer is producing some items, whereas there is one Consumer that is consuming the items produced by the Producer. The same memory buffer is shared by both producers and consumers which is of fixed-size. The task of the Producer is to produce the item, put it into the memory buffer, and again start producing items. Whereas the task of the Consumer is to consume the item from the memory buffer.

Conclusion

Firstly, the introduction of topic i.e., what basically is IPC is mentioned. Then the approaches or different mechanisms in which the IPC is implemented. Second, it is seen about the implementation of IPC in early systems like System V based on UNIX. And lastly, we ended with the problems we can face if IPC isn’t implemented properly.