Inter Process Comunication in Linux by Dr P.Padmanabham Professor (CSE)&Director Bharat Institute of Engineering &Technology Hyderabad Mobile

Topics Introduction to IPC Pipes FIFOs (Named Pipes) Message queues Kernel support and API for message queues Client/server example for message queues Semaphores Kernel support and API for semaphores Shred memory- kernel support. Semaphore and shred memory example.

Introduction to IPC In modern computer programming, IPC is an essential part. The mechanism through which two processes communicate (ie send and/or receive information ) is known as IPC. The two processes communicating may be on the same machine or on different machines (hosts). In fact network programming basically needs ipc between processes on different hosts. The IPC between processes in same machine essentially used for locking, mutual exclusion, making output of one process to be the input of other process etc.

pipes A pipe is simple circular buffer of fixed size written by one process and read by another int pipe(int pipefd[2]) : creates a pipe and returns two file descriptors, pipefd[0] and pipefd[1] for reading and writing. OS (kernel) enforces mutual exclusion : only one process at a time can access the pipe. Pipes are accessed by a file descriptor, like an ordinary file using read and write system calls. Processes sharing the pipe must have same parent in common and are unaware of each other's existence. Pipes are unidirectional. That is a process cannot read and write into the same pipe. Example programs: ppipe1.c, pipe2.c

FIFOs FIFO stands for First In First Out Unlike pipes, a FIFO has a name associated with it, allowing unrelated processes to access a single FIFO FIFOs are also referred as named pipes. A pipe is created and opened for read write in one system call – pipe where as FiIFO needs three system calls to create and open for read & write. System call to create a FIFO is Int mknod(char *path, int mode, int dev); The path name is same as unix path name and this will also be the name of the FIFO.

FIFOs (contd) The mode specifies the permissions. However the octal permissions are to be logically or’ed with S_IFIFO (in sys/stat.h) and passed to mknod. The dev specifies device number and is ignored ( by passing 0 ) to create a FIFO. Once the FIFO is created it must be opened for read 0r write by using open system call or any library function that opens a file like fopen(). After the creation normally one process opens the FIFO for read while the other process opens for write. Thus making three system calls (mknod,open,open) to create and use a FIFO.

Client/server Example using FIFO Two pipes are to be created and should be available to both server and client. One FIFO (say FIFO1) is opened in read mode by server the same FIFO1 should be opened in write mode by client. This will be used to send info from client to server. The second FIFO(say FIFO2) will be used for sending info from server to client by appropriately opening FIFO2. The order of opening is important to avoid deadlock. Alternatively one can use O_NDELAY flag with open to avoid deadlock. See Eample: fifoserv.c iffocli.c.

Streams and messages Pipes and FIFOs used the stream I/O model There are no boundaries- means reads and writes do not examine the data at all. When say 100 bytes are read from the pipe/FIFO it may be one process has written 55 and the other 45- this is not known to the reader process. Sometimes it is necessary that the process should know where the boundaries of the message and which process has sent the message and is the message sent ios addressed to this process or not. An ipc that provides all the above and more is “Message Queues”

System V IPC message queues Semaphores Shared memory The above are known as system V IPC They do not use the stream approach as pipes or fifos. Basically they do not use read, write and other system calls used by streams

System V IPC - API Message queues semaphoresShared memory Include file System call to open or createmsggetsemgetshmget System calls for control operations msgctlsemctlshmctl System calls for IPC operationsmsgsnd msgrcv semopshmat shmdt

Kernel support for system V IPC kernel maintains the following structure for each ipc channel created Struct ipc_perm { u_short uid; u_short gid; u_short cid; // creators uid u_short cgid; u_short mode; // permissions u_short seq; // slot usage sequence number ey_t key; // key } Note: u_short is unsigned short (16 bits)

ftok() All three get system calls use a key of the type key_t and return an integer identifier. all the people that use the IPC channel must know the key ftok() fuction can be used to generate the key once all the people using the ipc channel agree on a common path name and a project no like 1,2 etc. Key_t ftok( char *pathname, char * projno); Thus an unique key is generated by all the users of the channel

In place of key if IPC_PRIVATE is passed to get system call, a unique key is generated. No combination of paths are proj nos used with ftok can crate IPC_PRIVATE All the three get system calls in addition to key may also use some special flags IPC_CREAT and IPC_EXCL Flags in get system calls

Logic for creating or opening an IPC channel flag argumentKey does not existKey already exists No special flagerror erno set to ENOENT OK IPC_CREATOk, create new entry OK IPC_CREAT|IPC_EXCLOk, create new entrySet erno to EEEXIT

All messages are stored in the kernel and are associated with a queue identifier which is returned by kernel to the process when msgget() is called. Processes can write and read messages from the queue using queue identifier. There is no need for any process to wait to receive a message unlike pipes and FIFOs. Note that we will be using msgsnd and msgrcv and not read and write. Message queues

A new message queue is created or accessed with msgget system call. #include Int msgget(key_t key,int msgflags); The value returned by msgget is message queue identifier or -1 if an error has occurred. API for Message queues

To write a message we use the system call Int msgsnd(int msgqid, struct msgbuf *ptr,int length, int flag); length- length of message struct msgbuf { long mtype; char mtext[100]; } ; Flag could be IPC_NOWAIT API for Message queues(CONT.)

To receive a message: int msgrcv(int msqid, struct msgbuf *ptr,int length, long msgtyp, int msgflg); The only extra parameter is msgtyp. To delete a message queue: Int msgctl(int msqid,int cmd,struct msqid_ds*buff) We will use only cmd of IPC_RMID to remove a message queue and the last parameter is NULL. API for Message queues(CONT.)

The purpose of having type for a message is to allow several processes to multiplex their messages into a single queue. Several clients can write into one queue created by a server message including their pid as a part of the message. All client to server messages will have a specific type (say 1) to allow server to know the pisds of all clients.. The server can send messages to a specific client with its pid as type. Multiplexing Message queues

A semaphore is nothing but a term used in UNIX for a non-negative integer variable which acts as a counter. A semaphore whose value is either 0 0r 1 is called a binary semaphore (mutex) Binary semaphore is mainly used for locking or mutual exclusion. A semaphore is not a single value but a set of non- negative integers Each value in the set is not restricted to 0 or 1. Semaphores

A new set of semaphores are created or accessed with semget system call. #include Int semget(key_t key, int nsem,int semflags); The value returned by semget is semaphore identifier or -1 if an error has occurred and nsem is the number of semaphores in the set. For every set of semaphores created, the kernel maintains a structure semid_ds (like msqid_ds). Kernel support and API for semaphores

The operations are performed on one or more semaphores in the set by using semop system call. int semop(int semid, struct sembuf *opptr, unsigned int nops); opptr pointer points to an array of the following structures and the array size is specified by nops struct sembuff{ ushort sem_no; /* semaphore # */ short sem_op ; /* semaphore operations */ short sem_flg; /* semaphore flags */ }; Semaphore API (contd.)

The array of operations passed to the semop call are guaranteed by the kernel to be atomic. The kernel does all the operations specified or none of them. 1. if sem_op value is +ve this is added to the current semaphore value. 2. if sem_op value is 0 the caller wants to wait till the value becomes zero. 3. if sem_op is –ve the caller wants to wait unit the value becomes greater than or equal to the absolute value of sem_op and then the absolute value is subtracted from the current value of the semaphore. Semaphore API (contd.)

The semctl system call provides various control operations on a semaphore. int semctl(int semid, int semnum, int cmd, union semun arg); union semun{ int val; /* used for SETVAL only */ struct semid_ds *buff; /* used for IPC_STAT and IPC_SET */ ushort *array; /* used for GETALL & SETALL */ } arg; Semnum is semaphore number, cmd is the command. Semaphore API (contd.)

We will use a cmd of IPC_RMID to remove a semaphore from the system We will also use GETVAL & SETVAL to fetch and set specific semaphore value. The GETVAL command returns the semaphore value of the semaphore specified by semnum. The SETVAL command sets the semaphore’s value to arg.val, for the semaphore specified by semnum. Other commands are IPC_STAT, IPC_SET,GETALL,SETALL. Semaphore API (contd.)

The following functions can be used to implement and control semaphores Id=sem_create((key,initval); /*creates semaphore with initial value or open */ Id=sem_open(key); /* give access (must exist already) */ Sem_wait(id) ;/* down by 1 p operation */ Sem_signal(id); /* up by 1 v operation */ Sem_op(id,amount); /* wait if amout 0 */ Sem_close(id); /* close the access */ Sem_rm(id); /* delete */ Some functions to implement Semaphores in system V

Shred memory reduces the number of reads and writes when data has to be transferred from sever process to client process when compared to pipes or FIFOs The server gets access to a shared memory segment using a semaphore. Server reads the input file to shared memory directly. When the read is complete the server notifies the client again through a semaphore. The client writes the shared memory segment directly to output file. Shared Memory

A shared memory segment is created or accessed with shmget system call. #include Int shmget(key_t key, int size,int shmflags); The value returned by shmget is shared memory identifier or -1 if an error has occurred and size is the number of bytes required in shared memory. For every segment of shared memory created, the kernel maintains a structure shmid_ds. Kernel support and API for shared memory

To be able to use the memory we use a system call shmat (shred memory attach). Char* shmat(int shmid, char *shmaddr, int flags); shmat retuns the address of the shared memory segment. Normally shmaddr is set to 0 to allow kernel to choose the address, flags can be set to SHM_RDONLY if the segment to be made read only to the process otherwise is set to 0. When a process finishes with the shared memory segment it detaches the segment by calling shmdt. Int shmdt(char * shmaddr); API for shared memory

The shmdt sytyem call does not delete the shared memory segment, it simply prevets the read write into the segment by the process. The shared memory is deleted using shmctl system call. Int shmctl(int shmid, int cmd, struct shmid_ds *buff); A cmd IPC_RMID removes the shared memory from the system. API for shared memory(contd)