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.

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