Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Performance Analysis of IPC Mechanisms Srivats Ubrani Anantharam Bharadwaj Department of Computer Science George Mason University I. ABSTRACT Inter-process communication (IPC) refers to the coordination of activities among processes. A common example of this is managing access to a given system resource. Unix-based operating systems feature several forms of Inter-Process Communication Mechanisms including Pipes, UNIX domain sockets, named pipes (or FIFO), Semaphores and Signals. Although each of these were designed to perform a similar service, there do vary in levels of performance. To carry out IPC, some form of active or passive communication is required. Systems for managing communication and synchronization between cooperating processes are essential to many modern operating systems. IPC has played a major role in UNIX based operating systems. The analysis of pipes, message queues and shared memory involved examining the code written to transfer data among two different processes. The programs were run and throughput were measured on Intel-i7 processor. It was observed that the pipes were faster when compared to message queues and shared memory. This paper describes the methodology of profiling the code for analyzing the performance of these IPC mechanisms. II. INTRODUCTION Among all vital aspects of an operating system, process management is the foremost responsibility of an operating system. A good OS must provide methods for processes to communicate with each other. Such methods are known as Inter-process Communication (IPC) mechanisms. These mechanisms allow communication and sharing of information between processes. Also they provide ways to modularize the OS and parallelize programs for computational speedup [1]. Regular files are not a feasible means of communication medium for parallel processes. For example, a reader/writer situation in which processes writes data and the other process reads them. The file should also keep track of all data transmitted that consumes disk space. A. PIPES There are no simpler form of IPC as pipes [2]. Pipes provide a means for communication between two processes. The pipe call returns a pair of file descriptors in read mode and in write mode. A pipe behaves like a queue. The first thing written to the pipe is the first thing read from the pipe. Writes (calls to write on the pipe’s input descriptor) fill the pipe and block when the pipe is full. They block until another process reads enough data at the other end of the pipe and return when all the data given to write have been transmitted. Reads (calls to read on the pipe’s output descriptor) drain the pipe. If the pipe is empty, a call to read blocks until at least a byte is written at the other end. It then returns immediately without waiting for the number of bytes requested by read to be available. B. MESSAGE QUEUES Message queues provide an asynchronous communications protocol, which means that the sender and receiver do not need to interact with the message queue at the same time. Message queues have limits on the size of data that may be transmitted in a single message and the number of messages that may be sent on the queue. Different operating systems have different implementations of message queues are they are designed for specific purposes. Message queue is created using msgget() that takes key as an argument and returns descriptor of the queue if the queue exists. The flag IPC_CREAT is used to create the message queue. The receiver function uses msgrcv() to receive messages from the queue of a specified message type. Finally, the msgctl() method is used to destroy a message queue after it by passing IPC_RMID flag[3].
  2. 2. C. SHARED MEMORY Shared memory is the fastest form of IPC available. It allows the processes to share a region of memory. Once the memory is mapped into the address space of the processes that are sharing the memory region, no kernel involvement occurs in passing data between the processes. The processes must synchronize the usage of the shared region of memory among themselves. The user can create/destroy/open this memory using a shared memory object. III. METHODOLOGY Each IPC mechanism was implemented as simple program that used the interfaces to transfer data to a different process using a buffer of fixed size. The performance was calculated based on the amount of data read by the receiver in different intervals of time. Calculating the amount of data received by a process based on real time shows the efficiency of the IPC mechanism. A. REAL TIME MEASUREMENT The C programming language offers clock and time functions for measuring time in terms of system wide clock or CPU clock cycles. One such function clock_gettime() is used in this project. These functions are defined in <time.h>. The argument tp belong to the timespec struct. The clk_id argument of clock_gettime() function is the identifier of the particular clock on which to act. It is in this argument where the type of clock is specified. The system wide clock is accessible to all processes [4]. IV. DESIGN OF IPC PROGRAMS FOR ANALYSIS The programs for IPC were written to measure the data transferred between two processes in t seconds on 4GB RAM Ubuntu OS on Virtual Machine. The high level design of each IPC are discussed below. A. IMPLEMENTATION OF PIPES A call for pipe() is made to open a pipe before the fork() command. In the parent process the read end of the pipe is closed and the data is written into the pipe enclosed in a forever loop. In every iteration of the loop the data is written into the pipe. After this the parent process waits for the child to terminate. The timespec struct has precision for measuring time seconds as well as nanoseconds. The structure is defined in <time.h>: struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; B. REAL TIME MEASUREMENT In all the implementations of IPC the process that reads data, reads in infinite loop. The loop breaks out once the clock exceeds the time interval specified. The pseudocode of this logic is specified below: while(true) { get_time(start_time); read_data(bytes); get_time(end_time); if(end_time – start_time >t)) { /* Exit the program */ } } In the child process the time of the system wide clock is retrieved by clock_gettime() function. The process reads data from the pipe for specified amount of time. At last the number of bytes read in the entire duration is noted. Below is the pseudocode of pipes program. pipe(p); fork(); if(parent){ for(;;) { /* write to the pipe forever */ } } else if(child){ get_time(start_time); read_from_pipe(bytes); get_time(end_time); if(end_time – start_time >t)) /* Exit the program */ C. IMPLEMENTATION OF MESSAGE QUEUES Message queues are implemented in two programs as a sender and receiver of messages. The sender program sends messages in an infinite loop. The receiver program receives the data for a t seconds.
  3. 3. Below is a pseudocode for sender program: while(1) { // Send the message using msgsnd msgsnd(); } Below is a pseudocode for receiver program: // Receive the message using msgrcv for(;;) { get_time(start_time); msgrcv(); get_time(end_time); } } D. IMPLEMENTATION OF SHARED MEMORY The shared memory is implemented in parent child process where each process shall access the memory segment to read and write. The memory region is created using msget() is of SHMSIZE bytes specified in the program. The pseudocode of the program is given below: if(fork>0) { // Create the shared memory using IPC_CREAT flag shmget(IPC_CREAT); // Attach the shared memory to calling process shm = shmat(shmid, 0, 0); for(;;) { memset(shm,'a',SHMSIZE); } wait(NULL); // wait for child to terminate exit(); } else { // Child process // Attach to memory segment using shmid. for(;;){ get_time(start_time); read_from_shm(); get_time(end_time); if(end_time - start_time >t) { //Exit the program } } } V. OBSERVATIONS After the programs were run for different intervals of time the bytes transferred were noted at each time interval. They were plotted with time in X- axis against data in Y-axis. The outputs are discussed below. A. ANALYSIS OF PIPES Although pipes are the simple forms of IPC as they are unidirectional channels for transferring data, they are not the fastest mode of IPC. For the time interval of 2 seconds, pipes could transfer approximately around 212 MB of data. At the end of 8 seconds 758 MB of data was transferred. The average performance of pipes was found to be 95 MB/s. Fig 5.1: Performance of Pipes B. ANALYSIS OF SYSTEM V MESSAGE QUEUES Message queues were faster than pipes, yet much slower than shared memory. After 2 seconds, 238MB of data was received by the client process. The average amount of data transferred would amount to 120MB/s.
  4. 4. Fig 5.2: Performance of Message Queues C. ANALYSIS OF SHARED MEMORY The shared memory is the fastest mode of IPC. Probably because there is less kernel involvement in this form apart from allocating memory segment and attaching it to the caller process. In 2 seconds, 8 GB of data was written into a memory segment. The average amount of data written was around 4GB/s. VI. CONCLUSION Using a fixed buffer size of 4K the data transfer speed of shared memory was found to be the highest. Hence, shared memory is the fastest form of IPC followed by message queues and pipes. VII. ACKNOWLEDGEMENT Thanks goes to Professor Harold M Greenwald for encouraging me to do a research on this topic. VIII.REFERENCES [1] Kwame Wright, Karthik Gopalan, Performance Analysis of Various Mechanisms for Inter-process Communication. [2] es.html. [3] Linux man page, [4] Linux page, Fig 5.3: Performance of Shared Memory