System Programming - Interprocess communication
1 like155 views
This document provides an overview of interprocess communication (IPC) structures. It discusses pipes, which allow for one-directional data flow between related processes using file descriptors. It also covers FIFOs which are similar to pipes but use pathnames and can be accessed by unrelated processes. The document outlines the main XSI IPC structures - message queues for communication via linked lists of messages, semaphores for controlling access to shared resources, and shared memory for processes to access the same memory region. It provides details on how each IPC structure is created, accessed, and removed in UNIX systems.
![PIPES
• Oldest and most widely implemented form of IPC
• Data can flow in one direction (half duplex)
• Pipes must be used in related processes since their
identifier is the file descriptor
• pipe creates a pipe and places 2 file descriptors
inside fd. fd[0] is opened for reading and fd[1]
for writing
• Pipes work in a FIFO fashion
#include <unistd.h>
int pipe(int fd]);
Return 0 if OK, 1 on error](https://image.slidesharecdn.com/interprocesscommunication-150824073849-lva1-app6892/85/System-Programming-Interprocess-communication-4-320.jpg)
![MESSAGE QUEUES
• The ptr argument points to a long integer that contains
the positive integer message type and is immediately
followed by the data. We can use a struct like:
#include <sys/msg.h>
int msgsnd(int msqid, const void* ptr,
size_t nbytes, int flag);
Returns -1 on error
struct mymesg {
long mtype; // Positive message type
char mtext[512]; // Message data
}](https://image.slidesharecdn.com/interprocesscommunication-150824073849-lva1-app6892/85/System-Programming-Interprocess-communication-19-320.jpg)
![SEMAPHORES
#include <sys/types.h>
#include <sys/sem.h>
#include <sys/ipc.h>
int semop(int semid, struct sembuf
semoparray[], size_t nops);
Return 0 if OK, 1 on error
struct sembuf {
unsigned short sem_num; // Member # in set
short sem_op; // Operation
short sem_flg; // IPC_NOWAIT/SEM_UNDO
}](https://image.slidesharecdn.com/interprocesscommunication-150824073849-lva1-app6892/85/System-Programming-Interprocess-communication-32-320.jpg)
System Programming - Interprocess communication
- 1. SYSTEMS PROGRAMMING LECTURE 7 INTERPROCESS COMMUNCATION
- 2. INTERPROCESS COMMUNICATION • IPC allows different processes to communicate between themselves • So far, processes could communicate using fork/child inheritance, passing arguments in exec calls, through the file system and using signals • There are more structures which allows proceses to communicate more efficiently • IPC structures provide different flavors of communication • Some can only be used between realated processes (fork/child). Unnamed structures
- 3. INTERPROCESS COMMUNICATION • Named structures can be used by anyone having access rights • System V IPC structures follow the same access protocol, but some extra form of initial communication is necessary for the processes to use them • Different implementations might support one type of IPC and not another • Some structures are handled differently between implementations
- 4. PIPES • Oldest and most widely implemented form of IPC • Data can flow in one direction (half duplex) • Pipes must be used in related processes since their identifier is the file descriptor • pipe creates a pipe and places 2 file descriptors inside fd. fd[0] is opened for reading and fd[1] for writing • Pipes work in a FIFO fashion #include <unistd.h> int pipe(int fd]); Return 0 if OK, 1 on error
- 5. PIPES • fstat return st_mode of FIFO which can be tested by the S_ISFIFO macro • We use normal read, write and close operations to access pipes • If we read from a pipe whose write end has been closed, read returns 0, showing an end of file • If we write to a pipe whose read end has been closed, write returns -1 with errono EPIPE, and SIGPIPE is generated • The constant PIPE_BUF gives the maximum amount of bytes that can be written in one go without interleaving between different writers
- 6. PIPES • Within one process, a pipe is useless • We normally fork a child process and then close one side of the parent and close the other side in the child
- 7. FIFOS • FIFOs are just like normal files but they behave like pipes with a pathname • FIFOs are full duplex and more than one process can open a FIFO • Other unrelated processes can access FIFOs using normal open, read, write and close system calls • To remove a FIFO file, call unlink • Normal access file permissions apply. The stat function returns the type as FIFO like pipes (in ls marked with a ‘p’)
- 8. FIFOS • If we write to a FIFO which no process has opened for reading, SIGPIPE is generated • When no writer exists, a read returns 0 for EOF • A FIFO can be created with mkfifo • mode in mkfifo is the same as mode in open for file access permissions #include <sys/stat.h> int mkfifo(const char* path, mode_t mode); Return 0 if OK, 1 on error
- 9. FIFOS • When we open a FIFO, the O_NONBLOCK flag affects what happens: • If not specified, an open for read-only blocks until a two way communication exists • If specified an open for read-only returns immediately. An open for write-only returns with error -1 and errno ENXIO unless another process has opened the FIFO for reading • If we write to a FIFO that no process has opened for reading the signal SIGPIPE is generated
- 10. XSI IPC • The three types of IPC referred to as XSI IPC (message queues, semaphores and shared memory) have many similar features • All these structures use the same access protocol • Each IPC has a key associated with it • This key is global to the whole system (kernel) • Two processes using the same key will be given access to the same IPC structure • In supplying the key an identifier is returned, which is then used to operate in the IPC. This identifier is unique to the whole system too
- 11. XSI IPC • Keys and identifiers will run out in the system if no IPC structures are removed • A special key exists: IPC_PRIVATE which is guaranteed to be an unused key • The identifier or key must somehow be passed between different processes using the same IPC structure • Keys or identifiers can be passed between processes using the filesystem, command line values, an agreed upon header, parent/child inheritance or using ftok.
- 12. XSI IPC • ftok converts an agreed upon pathname and project ID into an IPC key • The general format to obtain an identifier is Xget(key, flag) • If a key is passed the second process will have to ‘re- create’ the IPC structure, if the identifier is passed, second process will access the IPC using this identifier #include <sys/types.h> #include <sys/ipc.h> key_t ftok(char *pathname, char projID);
- 13. XSI IPC • A new IPC structure will be created if the key is equal to IPC_PRIVATE or a new key is given and IPC_CREAT is specified in flag (in Xget) • Using IPC_EXCL with IPC_CREAT in flag will produce and error with errno set to EEXIST if an IPC already exists with the same key • When creating an IPC, access permissions are given in flag of Xget
- 14. XSI IPC Permission Message Queues Semaphore Shared Memory user-read user-write MSG_R MSG_W SEM_R SEM_A SHM_R SHM_W group-read group-write MSG_R >> 3 MSG_W >> 3 SEM_R >> 3 SEM_A >> 3 SHM_R >> 3 SHM_W >> 3 other-red other-write MSG_R >> 6 MSG_W >> 6 SEM_R >> 6 SEM_A >> 6 SHM_R >> 6 SHM_W >> 6
- 15. MESSAGE QUEUES • This is a linked list of messaged stored within the kernel • msgget opens an existing queue, or creates a new one, and returns the IPC queue identifier • msgctl is used to remove the structure created by the same effective user. Removal is immediate and anyone using the structure will get an error EIDRM #include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h> int msgget(key_t, int flag) Returns message queue ID, -1 on error int msgctl(int msgid, IPC_RMID, NULL) Returns -1 on error
- 16. MESSAGE QUEUES • Each queue has the structure above associated with it • It defines the current status of the queue struct msqid_ds { struct ipc_perm msg_perm; msgqnum_t msg_qnum; msglen_t msg_qbytes; pid_t msg_lspid; pid_t msg_lrpid; time_t msg_stime; time_t msg_rtime; time_t msg_ctime; . . . }
- 17. MESSAGE QUEUES • Some limits exist for message queues: • MSGMAX: largest message allowed in bytes • MSGMNB: max size of a queue in bytes • MSGMNI: max number of queues, system wide • MSGTQL: max number of messages, system wide • Each message consists of a positive long value specifying the message type followed by data • Messages are always places at the end of the queue
- 18. MESSAGE QUEUES • The cmd argument specifies the command to be performed on the queue: • IPC_STAT: Fetch msqid_ds structure of the queue • IPC_SET: Set some structure values to queue • IPC_RMID: Remove message queue from the system and any data still on the queue #include <sys/msg.h> int msgctl(int msgid, int cmd, struct, msqid_ds *buf) Returns -1 on error
- 19. MESSAGE QUEUES • The ptr argument points to a long integer that contains the positive integer message type and is immediately followed by the data. We can use a struct like: #include <sys/msg.h> int msgsnd(int msqid, const void* ptr, size_t nbytes, int flag); Returns -1 on error struct mymesg { long mtype; // Positive message type char mtext[512]; // Message data }
- 20. MESSAGE QUEUES • A flag of IPC_NOWAIT can be specified • If message queue is full causes msgsnd to return immediately with EAGAIN • If not specified, call is blocked until there is room, queue is removed or signal is caught • Since a reference count is not maintained with each message queue the removal of a queue simply generates errors on the next queue operation • When msgsnd returns successfully, the msqid_ds structure is updated
- 21. MESSAGE QUEUES • If returned message is larger than nbytes and MSG_NOERROR is set in flag, the message is truncated (without warning) • Otherwise E2BIG is returned • type argument lets us specify which message we want #include <sys/msg.h> int msgrcv(int msqid, void* ptr, size_t nbytes, int flag); Returns -1 on error
- 22. MESSAGE QUEUES • type == 0: the first message on the queue is returned • type > 0: first message on the queue whose message type equals type is returned • type < 0: first message whose message type is the lowest value less than or equal to abs(type) is returned • A nonzero type is used to read the messages in an order other than first in, first out • IPC_NOWAIT will make the operation non- blocking, ENOSMG if message type doesn’t exist
- 23. POSIX MESSAGE QUEUES • Much nicer interface • Queues are reference counted (only removed when all processes are detached from it) • Visible on a pseudo-filesystem • Notion of message priority • Message notification system, where processes can register to receive notifications when a new message arrived on an empty queue (action is signal or start new thread)
- 24. SEMAPHORES • Counter used to provide access to shared data for multiple processes • When a semaphore is positive a process decrements the semaphore by 1 signifying it has used up one resource • When the semaphore is 0 it means the resource is not available and the process blocks until the resource is available • Testing and decrementing is done atomically to guarantee functionality
- 25. SEMAPHORES • Semaphores are created in sets with each set holding one or more semaphores • The are limits affecting semaphores: • SEMVMX: max value of semaphore • SEMMNI: max number of system-wide semaphore sets • SEMMNS: max number of system-wide semaphores • SEMMSL: max number of semaphores per set • SEMOPM: max number of operations per semop call
- 26. SEMAPHORES • XSI semaphores are a complicated implementation of semaphores: • The use of semaphore sets instead of single independent ones • The creation and initialisation of semaphores are independent (not performed atomically) • We have to worry about a program that terminates without releasing its allocated semaphores • The kernel maintains a similar structure to msqid_ds for each semaphore and semaphore set
- 27. SEMAPHORES struct semi_ds { struct ipc_perm sem_perm; unsigned short sem_nsems; timet_t sem_otime; // last semop time timet_t sem_ctime // last-change time . . . } struct { unsigned short semval; // Semaphore value pid_t sempid; // pid of last operation unsigned short semcnt; // #procs semval>curval unsigned short semzcnt; // #rpocs semval==0 }
- 28. SEMAPHORES • Obtain a semaphore ID with specified number of semaphores in set • If referencing an existing set, nsems can be 0 • semctl is a catchall for various semaphore implementations #include <sys/sem.h> int semget(key_t, int nsems, int flags); Returns ID is OK, 1 on error int semctl(int semid, int semnum, int cmd, ... /*union semun arg */);
- 29. SEMAPHORES • The cmd argument specifies one of the following ten commands to be performed on the specified set • The five command that refer to one particular semaphore use semnum to specify one member of the set • The value of semnum is between 0 and nsems-1 union semun { int val; // SETVAL struct semid_ds *buf; // IPC_STAT/IPC_SET unsigned short *array; // GETALL/SETALL }
- 30. SEMAPHORES • IPC_STAT: Fetch semid_ds structure for set • IPC_SET: Set structure fields • IPC_RMID: Remove semaphore from the system. Removal is immediate. Any other process using the semaphore will get an error on next attempted operation • GETVAL: Return value of semval for semnum • SETVAL: Set value of semval for semnum • GETPID: Return value of sempid for semnum
- 31. SEMAPHORES • GETCNT: Return value of semncnt for semnum • GETZCBT: Get value of semzcnt for semnum • GETALL: Fetch all semaphore values in the set • SETALL Set all semaphore values in set • For all GET commands other than GETALL, the function returns the corresponding value • For the remaining commands, the return value is 0 • The function semop atomically performs an array of operation on a semaphore set
- 32. SEMAPHORES #include <sys/types.h> #include <sys/sem.h> #include <sys/ipc.h> int semop(int semid, struct sembuf semoparray[], size_t nops); Return 0 if OK, 1 on error struct sembuf { unsigned short sem_num; // Member # in set short sem_op; // Operation short sem_flg; // IPC_NOWAIT/SEM_UNDO }
- 33. SEMAPHORES • nops arguments specifies the number of operation (elements) in the array • If sem_op is: • Positive: semaphore value is added by the value of sem_op (release) • 0: block until value becomes equal to 0 • Negative: if semaphore value is greater than or equal to abs(sem_op), semaphore is subtracted. Otherwise block until we can do this (wait)
- 34. SEMAPHORES • All blocking operations will fail if semaphore is removed (ERMID) or signal is caught (EINTR) • If flag is set to IPC_NOWAIT, semop never blocks and returns with errno EAGAIN when an operation was not successful • Typical semaphore usage: Access semaphore semop() with sem_op = -1 Use resource semop() with sem_op = 1 Access semaphore semop() with sem_op = -1 Use resource semop() with sem_op = 1 Create semaphore Set semaphore value to 1
- 35. SHARED MEMORY • This is an area of memory that can be used by one or more processes • One has to be careful in synchronising access to a given region by several processes • SHMMAX: max number of bytes in shared memory segment • SHMMIN: min number of byes in shared memory segment • SHMMNI: max number of system-wide shared memory segments • SHMSEG: max number of shared memory segments per process
- 36. SHARED MEMORY • Size is the minimum size of the shared memory segment desired (generally rounded up to page size) • If a new segment is being created we must specify size, client can specify a size of 0 • When a new segment is created the contents of the segment are initialised with zeros #include <sys/shm.h> int shmget(key_t key, int size, int flag); Return shm ID or -1 on error
- 37. SHARED MEMORY • cmd specifies one of the following commands: • IPC_STAT: Fetch shmid_ds structure for set • IPC_SET: Set structure fields • IPC_RMID: Remove shared memory segment from system. Attachment count is maintained for shared memory segments, segment is not removed until last process detaches it #include <sys/shm.h> int shmctl(int shimd, int cmd, struct shmid_ds *buf) Return 0 if OK, -1 on error
- 38. SHARED MEMORY • Two additional commands are provided for Linux and Solaris implementations: • SHM_LOCK: lock the shared memory segment in memory. Can be executed only by superuser • SHM_UNLOCK: Unlock shared memory segment. Can be executed only by superuser • Once a shared memory segment is created a process attaches it to its address space by using shmat
- 39. SHARED MEMORY • Address in the calling process at which the segment is attached depends on the addr argument and whether SHM_RND is specified in flag • If addr is 0, segment is attached at the first available address selected by the kernel (recommended) #include <sys/shm.h> void *shmat(int shmid, const void *addr, int flag); Return pointer to shared memory segment if OK, 1 on error
- 40. SHARED MEMORY • If addr is nonzero and SHM_RND is not specified, segment is attached at the address given by addr • If addr is nonzero and SHM_RND is specified, segment is attached at the address given by (addr – (addr % SHMLBA). SHMLBA is the low boundary address multiple and is always a power of 2. This rounds the address down to the next multiple of SHMLBA • It is unadvisable to specify and address
- 41. SHARED MEMORY • When we’re done with a shared memory segment we use shmdt to detach it • The addr argument is the value that was returned by a previous call to shmat • If successful, shmd will decrement the attachment counter in the associated shmid_ds structure #include <sys/shm.h> void *shmdt(void *addr); Return 0 if OK, 1 on error