1. Inter-process Communication (IPC)
Introduction
Inter-Process Communication, which in short is known as IPC, deals mainly with the techniques and mechanisms that facilitate communication between processes. Now, why do we need special separate mechanisms or techniques for communicating between processes? Why isn't it possible to have information shared between two processes without using such special mechanisms?
Let us start from something primitive. Imagine you have two glasses completely filled with water. One glass contains hot water and the other contains cold water. What can you do to make the temperature of water in both the glasses equal? The simplest answer will be to mix the water from both the glasses in a glass with much bigger capacity. Once water is mixed, the temperature becomes equal after some time. If one can remember, this will be framed as a problem with some numerical data in a High-School Physics examination. If we go by principles, then the phenomenon here is conduction. If we go by our topic of IPC, then we can say that since the two glasses were full, we had to use another glass with a larger capacity to mix the contents in order to balance their heat energy.
We know that some medium or other is required for communication between different processes. Similarly, when it comes to computer programs, we need some mechanism or medium for communication. Primarily, processes can use the available memory to communicate with each other. But then, the memory is completely managed by the operating system. A process will be allotted some part of the available memory for execution. Then each process will have its own unique user space. In no way will the memory allotted for one process overlap with the memory allotted for another process. Imagine what would happen otherwise!
The operating system's kernel, which has access to all the memory available, will act as the communication channel. Similar to our earlier example, where the glass with hot water is one process address space, the glass with cold water is another, and the glass with the larger capacity is the kernel address space, so that we pour both hot water and cold water into the glass with larger capacity.
What next? There are different IPC mechanisms which come into use based on the different requirements. In terms of our water glasses, we can determine the specifics of both pouring the water into the larger glass and how it will be used after begin poured.
The IPC mechanisms can be classified into the following categories as given below:
a. pipes
b. fifos
c. message queues
d. Semaphores A. Pipes
Pipes were evolved in the most primitive forms of the Unix operating system. They provide unidirectional flow of communication between processes within the same system. In other words, they are half-duplex, that is, data flows in only one direction. A pipe is created by invoking the pipe system call, which creates a pair of file descriptors. These descriptors point to a pipe inode and the file descriptors are returned through the filedes argument. In the file descriptor pair, filedes[0] is used for reading whereas filedes[1] is used for writing.
Let me explain a scenario where we can use the pipe system call: consider a keyboard-reader program which simply exits after any alpha-numeric character is pressed on the keyboard. We will create two processes; one of them will read characters from the keyboard, and the other will continuously check for alpha-numeric characters. Let us see how the filedes returned by pipe can be of use in this scenario:
#include
#include
#include
#include
#include
#include

int filedes[2];

void *read_char()
{
char c; printf("Entering routine to read character.........\n"); while(1) { /* Get a character in 'c' except '\n'. */ c = getchar(); if(c == '\n') c = getchar(); write(filedes[1], &c, 1); if(isalnum(c)) { sleep(2); exit(1); } }
}

void *check_hit()
{
char c; printf("Entering routine to check hit.........\n"); while(1) { read(filedes[0], &c, 1); if(isalnum(c)) { printf("The key hit is %c\n", c); exit(1); } else { printf("key hit is %c\n", c); } }
}

int main()
{
int i; pthread_t tid1, tid2; pipe(filedes); /* Create thread for reading characters. */ i = pthread_create(&tid1, NULL, read_char, NULL); /* Create thread for checking hitting of any keyboard key. */ i = pthread_create(&tid2, NULL, check_hit, NULL); if(i == 0) while(1); return 0;
}
The read_char function simply reads a character other than '\n' from the keyboard and writes it to filedes[1]. We have the thread check_hit, which continuously checks for the character in filedes[0]. If the character in filedes[0] is an alpha-numeric character, then the character is printed and the program terminates.
One major feature of pipe is that the data flowing through the communication medium is transient, that is, data once read from the read descriptor cannot be read again. Also, if we write data continuously into the write descriptor, then we will be able to read the data only in the order in which the data was written. One can experiment with that by doing successive writes or reads to the respective descriptors.
So, what happens when the pipe system call is invoked? A good look at the manual entry for pipe suggests that it creates a pair of file descriptors. This suggests that the kernel implements pipe within the file system. However, pipe does not actually exist as such - so when the call is made, the kernel allocates free inodes and creates a pair of file descriptors as well as the corresponding entries in the file table which the kernel uses. Hence, the kernel enables the user to use the normal file operations like read, write, etc., which the user does through the file descriptors. The kernel makes sure that one of the descriptors is for reading and another one if for writing. B. FIFOs
FIFOs (first in, first out) are similar to the working of pipes. FIFOs also provide half-duplex flow of data just like pipes. The difference between fifos and pipes is that the former is identified in the file system with a name, while the latter is not. That is, fifos are named pipes. Fifos are identified by an access point which is a file within the file system, whereas pipes are identified by an access point which is simply an allotted inode. Another major difference between fifos and pipes is that fifos last throughout the life-cycle of the system, while pipes last only during the life-cycle of the process in which they were created. To make it more clear, fifos exist beyond the life of the process. Since they are identified by the file system, they remain in the hierarchy until explicitly removed using unlink, but pipes are inherited only by related processes, that is, processes which are descendants of a single process.
Let us see how a fifo can be used to detect a keypress, just as we did with pipes. The same program where we previously used a pipe can be modified and implemented using a fifo.
#include
#include
#include
#include
#include
#include
#include
#include
#include

extern int errno;

void *read_char()
{
char c; int fd; printf("Entering routine to read character.........\n"); while(1) { c = getchar(); fd = open("fifo", O_WRONLY); if(c == '\n') c = getchar(); write(fd, &c, 1); if(isalnum(c)) { exit(1); } close(fd); }
}

int main()
{
int i; pthread_t tid1; i = mkfifo("fifo", 0666); if(i < 0) { printf("Problems creating the fifo\n"); if(errno == EEXIST) { printf("fifo already exists\n"); } printf("errno is set as %d\n", errno); } i = pthread_create(&tid1, NULL, read_char, NULL); if(i == 0) while(1); return 0;
}
Compile this program using cc -o write_fifo filename.c. This program reads characters (keypresses), and writes them into the special file fifo. First the program creates a fifo with read-write permissions using the function mkfifo. See the manual page for the same. If the fifo exists, then mkfifo will return the corresponding error, which is set in errno. The thread read_char continuously tries to read characters from the keyboard.
Note that the fifo is opened with the O_WRONLY (write only) flag .
Once it reads a character other than '\n', it writes the same into the write end of the fifo. The program that detects it is given below:
#include
#include
#include
#include
#include
#include
#include
#include
#include

extern int errno;

void *check_hit()
{
char c; int fd; int i; printf("Entering routine to check hit.........\n"); while(1) { fd = open("fifo", O_RDONLY); if(fd < 0) { printf("Error opening in fifo\n"); printf("errno is %d\n", errno); continue; } i = read(fd, &c, 1); if(i < 0) { printf("Error reading fifo\n"); printf("errno is %d\n", errno); } if(isalnum(c)) { printf("The key hit is %c\n", c); exit(1); } else { printf("key hit is %c\n", c); } }
}

int main()
{
int i; i = mkfifo("fifo", 0666); if(i < 0) { printf("Problems creating the fifo\n"); if(errno == EEXIST) { printf("fifo already exists\n"); } printf("errno is set as %d\n", errno); } pthread_t tid2; i = pthread_create(&tid2, NULL, check_hit, NULL); if(i == 0) while(1); return 0;
}
Here, again, it first tries to create a fifo which is created if it does not exist. We then have the thread check_hit which tries to read characters from the fifo. If the read character is alphanumeric, the program terminates; otherwise the thread continues reading characters from the fifo.
Here, the fifo is opened with the flag O_RDONLY.
Compile this program with cc -o detect_hit filename.c. Now run the two executables in separate terminals, but in the same working directory. Irrespective of the order in which you run, look for the message fifo already exists on the console. The first program (either of the two) that you run will not give any error message for creation of the fifo. The second program that you run will definitely give you the error for creation of the fifo. In the terminal where you run write_fifo, give input to standard output from your keyboard. You will get the message regarding the key hit on the keyboard on the terminal running the executable detect_hit. Analyze the working of the two programs by hitting several keys.
I have used two different programs for exhibiting the usage of fifos. This can be done within a single program by forking the routines which are called in the two program as threads. But I did this to show that unlike pipes, fifos can be used for communication between unrelated processes.
Now try running the program again. You will get the message that the fifo already exists even when you first run either of the two programs. This shows that fifos are persistent as long as the system lives. That is, the fifos will have to be removed manually - otherwise they will be permanently recognized by the file system. This is unlike pipes which are inherited as long as the process that created the pipe is running. Once this process dies, the kernel also removes the identifiers (file descriptors) for the pipe from the the file tables.
The usage is rather simple and the main advantage is that there is no need for any synchronization mechanism for accesses to the fifo. There are certain disadvantages: they can only be used for communication between processes running on the same host machine. Let us explore other IPC mechanisms to see what have they in store.

C. Message Queues
Message queues are one of the three different types of System V IPC mechanisms. This mechanism enables processes to send information to each other asynchronously. The word asynchronous in the present context signifies that the sender process continues with its execution without waiting for the receiver to receive or acknowledge the information. On the other side, the receiver does not wait if no messages are there in the queue. The queue being referred to here is the queue implemented and maintained by the kernel.
Let us now take a look at the system calls associated with this mechanism. msgget: This, in a way similar to shmget, gets a message queue identifier. The format is int msgget(ket_t key, int msgflg);
The first argument is a unique key, which can be generated by using ftok algorithm. The second argument is the flag which can be IPC_CREAT, IPC_PRIVATE, or one of the other valid possibilities (see the man page); the permissions (read and/or write) are logically ORed with the flags. msgget returns an identifier associated with the key. This identifier can be used for further processing of the message queue associated with the identifier. msgctl: This controls the operations on the message queue. The format is int msgctl(int msqid, int cmd, struct msqid_ds *buf);
Here msqid is the message queue identifier returned by msgget. The second argument is cmd, which indicates which action is to be taken on the message queue. The third argument is a buffer of type struct msqid_ds. Each message queue has this structure associated with it; it is composed of records for queues to be identified by the kernel. This structure also defines the current status of the message queue. If one of the cmds is IPC_SET, some fields in the msqid_ds structure (pointed by the third argument) will be set to the specified values. See the man page for the details. msgsnd: This is for sending messages. The format is int msgsnd(int msqid, struct msgbuf *msgp, size_t msgsz, int msgflg);
The first argument is the message queue identifier returned by msgget. The second argument is a structure that the calling process allocates. A call to msgsnd appends a copy of the message pointed to by msgp to the message queue identified by msqid. The third argument is the size of the message text within the msgbuf structure. The fourth argument is the flag that specify one of several actions to be taken as and when a specific situation arises. msgrcv: This is for receiving messages. The format is ssize_t msgrcv(int msqid, struct msgbuf *msgp, size_t msgsz, long msgtyp, int msgflg);
Besides the four arguments mentioned above for msgsnd, we also have msgtyp, which specifies the type of message requested.
Let's take a look at an example of using message queues.
#include
#include
#include
#include
#include
#include
#include

#define NMSGS 5

extern int errno;

struct msgbuf { long mtype; char mtext[100];
};

int main()
{
int msgid; int i, nloop; struct msgbuf msgp;

char tmp_msg[100]; tmp_msg[0] = '\0';

msgid = msgget(9999, IPC_CREAT | 0666); if(msgid < 0) { printf("%d : Error number is %d\n", __LINE__, errno); exit(1); }

for(nloop=0;nloop