Unit 7

UNIT = 7

chapter name = INTERPROCESS
COMMUNICATION

1

Introduction
For two processes to communicate with each other, they must both
agree to it, and the operating system must provide some facilities
for the interprocess communication (IPC)

User process User process

Kernel

IPC between two processes on a single system

2

User process User process

Kernel Kernel

IPC between two processes on different systems

Several different methods of IPC
•Pipes
•FIFOs(named pipes)
•Message queues
•Semaphores
•Shared Memory
3

File and Record Locking

1) Advisory Locking versus Mandatory Locking

Advisory locking means that the operating system maintains a correct
knowledge of which files have been locked by which processes, but it does not
prevent some process from writing to a file that is locked by another process.

A process can ignore an advisory lock and write to file that is locked, if the process
has adequate permissions.

Advisory locks are fine for what are called cooperating processes.

Mandatory locks mean that the operating system checks every read and write
request to verify that the operation does not interfere with a lock held by a process.

4

2) File Locking versus Record Locking

File locking locks an entire file, while record locking allows a process to lock a
specified portion of a file.

The definition of a record for unix record locking is given by specifying a starting
byte offset in the file and the number of bytes from that position.

The System V lockf function has the calling sequence

#include<unistd.in>

int lockf ( int fd, int function, long size ) ;

F_ULOCK Unlock a previously locked region
F_LOCK Lock a region (Blocking)
F_TLOCK Test and lock a region(Non blocking)
F_TEST Test a region to see if it is locked

5

3) System V Release 2 Advisory Locking
With System V Release 3, mandatory file and record locking are provided.

System V record locking is really provided by the fcntl system call.
The lockf function is provided by the standard c library as an interface to the fcntl system call.

4) BSD Advisory Locking
The flock system call is provided to lock and unlock a file.
#include<sys/file.h>

int flock ( int fd, int operation);

fd is a file descriptor of an open file, and operation is built from the following
constants.

LOCK_SH shared lock
LOCK_EX Exclusive lock
LOCK_UN Unlock
LOCK_NB Don’t block when locking

6

Pipes:
A pipe provides a one-way flow of data.

A pipe is created by the pipe system call. int pipe ( int *filedes ) ;
Two file descriptors are returned- filedes[0] which is open for reading , and filedes[1]
which is open for writing.

User process
Read fd
Write fd

Kernel

Pipe

Flow of data
Pipe in a single process

7

Parent process Child process
Read fd fork Read fd
Write fd Write fd

Kernel

Pipe
Flow of data
Fig 3.5 pipe in a single process, immediately after fork

Pipes are typically used to communicate between two different processes in the
following way. First , a process creates a pipe and then forks to create a copy of
itself, as shown in fig 3.5

Next the parent process closes the read end of the pipe and the child process
closes the write end of the pipe
8


Write fd Read fd

Kernel

Pipe

Flow of data

Pipes between two processes

When user enters a command such as
who | sort | 1pr to create three processes with two pipes between them.

9

who process sort process 1pr process

Write fd Write fd Read fd
Read fd
Kernel

Pipe 1 Pipe 2

Flow of data Flow of data

Pipes between three processes in a shell pipeline

When a two-way flow of data is desired, we must create two pipes and use one for each
direction
•Create pipe 1, create pipe 2
•Fork
•Parent closes read end of pipe 1
•Parent closes write end of pipe 2
•Child closes write end of pipe 1
•Child closes read end of pipe2

10


Write 1 fd Write 2 fd
Read 2 fd Read 1 fd
Kernel

Pipe 1
Flow of data

Pipe 2

Flow of data

Two pipes to provide a bidirectional flow of data
The biggest disadvantage with pipes is that they can only
be used between processes that have a parent process in
common.
There is no way for two totally unrelated processes to
create a pipe between them and use it for IPC 11

Fork System Call

The fork system call creates a copy of the process that was executing.

The process that executed the fork is called the parent process and the
new process is called the child process.

The fork system call is called once but it returns twice.

1) The first return value in the parent process is the process ID of the
newly created child process.
2) The second return value in the child process is zero.

If the fork system call is not successful, -1 is returned

12

Two uses for fork operation.

1) A process wants to make a copy of itself so that one copy can
handle an operation while the other copy does another task.
example : Network servers.

2) A process wants to execute another program.

13

F I F Os
Pipes cannot be shared between unrelated processes. With FIFO
however we do not have this restriction.

FIFO stands for First In, First Out.

It is a one way flow of data, with the first byte written to it being
the first byte read from it.

FIFOs are also called named pipes.

14

A FIFO is created by the mknod system call

Int mknod ( char *pathname, int mode, int dev ) ;
Pathname = is the name of the fifo file .
Mode = The mode argument specifies the file mode access mode and is
logically or’ ed with the S_IFIFO flag.

It creates a new regular, directory, or special file.

value meaning
S_IFDIR directory

S_IFREG regular file

S_IFIFO named pipe

The dev value is ignored for a FIFO, except for device file. 15

Mknod() returns -1 if unsuccessful and 0 (zero) otherwise.

If a FIFO is opened by a process for both reading and writing, there
can’t be any waiting for a reader or writer.

16

#include <stdio.h>
#include<stdlib.h>
#include<sys/stat.h>
#include<unistd.h>
#define FIFO_FILE "MYFIFO“
int main(void)
{
FILE *fp;
char readbuf[80];
umask(0);
mknod(FIFO_FILE, S_IFIFO|0666, 0);
while(1)
{
fp = fopen(FIFO_FILE, "r");
fgets(readbuf, 80, fp);
printf("Received string: %sn", readbuf);

fclose(fp);
}
return(0);
}
17

Streams and messages

Draw backs of PIPES & FIFO

There are no record boundaries- reads and writes do not
examine the data at all.

A process reading 100 bytes from a pipe, for example, cannot
tell if the process that wrote the data into the pipe did a
single write of 100 bytes, five writes of 20 bytes, or two
writes of 50 bytes.

It could also happen that one process writes 55 bytes into
the pipe, followed by another process writing 45 bytes.

The data is a stream of bytes with no interpretation done by
the system. 18

We can also add more structure to either a pipe or FIFO.

We define a message in our mesg.h header file as

If we use the stream format for messages, with
newlines separating each message, the length is
implied by the newline character at the end of each
message

19

Name spaces
The set of possible names for a given type of IPC is called its
Name space.
The last column specifies how a process accesses a particular
form of IPC.
IPC Name space identification

Pipe (no name) File descriptor

FIFO Path name File descriptor

Message queue Key_t key identifier

Shared memory Key_t key identifier

semaphore Key_t key identifier

Socket-unix domain pathname File descriptor

Socket-other domain (domain dependent) File descriptor

Name spaces for IPC 20

Ftok converts a pathname and a project identifier to a
system V IPC key.
System V IPC keys are used to identify message queues, shared
memory, and semaphores.
#include <sys/types.h>
#include<sys/ipc.h>
Key_t ftok( char *pathname, char proj ) ;
The file <sys/types.h> defines the key_t datatype, which is
typically a 32-bit integer

If the pathname does not exist, or is not accessible to the
calling process, ftok returns -1.

Once the pathname and proj are agreed on by the client and
server, then both can call the ftok function to convert these
into the same IPC key. 21

System V IPC
Three types of IPC

1) Message queues

2) Semaphores are collectively referred to as System V IPC

3) Shared memory

Summary of System V IPC system calls.
MESSAGE SEMmAPHOR SHARED
QUEUE E MEMORY
Include file <sys/msg.h> <sys/sem.h> <sys/shm.h>

System call to create or open msgget semget shmget

System call for control msgctl semctl shmctl
operations
System calls for IPC msgsnd semop Shmat
operations msgrcv shmdt 22

The kernel maintains a structure of information for each IPC channel, similar to
the information it maintains for files
Struct ipc_perm {
ushort uid; /*owner’s user id */
ushort gid; /*owner’s group id*/
ushort cuid; /*creator’s user id*/
ushort cgid /*creator’s group id*/
ushort mode; /*access modes */
ushort seq; /* slot usage sequence number */
key_t key; /*key */
};

This structure, and other manifest constants for the System V IPC system
calls,are defined in <sys/ipc.h>.

The three ctl system calls are used to access this structure and modify it.

The three get system calls that create or open an IPC channel, all take a key
value, whose type is key_t, and return an integer identifier.

23

Generating IPC ids using ftok.

Char *path Msgget () int id
Key_t key
Ftok() Semget ()
Char proj Shmget ()

24

The rules for whether a new IPC channel is created or whether an existing one
is referenced are

Specifying a key of IPC_PRIVATE guarantees that a unique IPC channel is
created. There are no combinations of pathname and proj that cause ftok to
generate a key value of IPC_PRIVATE

Setting the IPC_CREAT bit of the flag word creates a new entry for the specified
key. It does not already exist. If an existing entry is found, that entry is
returned.

Setting both the IPC_CREAT and IPC_EXCL bits of the flag word creates a new
entry for the specified key, only if the entry does not already exist. If an
existing entry is found, an error occurs, since the IPC channel already exists.

Setting the IPC_EXCL bit, without setting the IPC_CREAT bit, has no meaning

25

Message queue
Process can send a message to another specific process.

Every message on the queue has the following attributes:

long integer type
Length of the data portion of the message
Data.

We can picture a particular message queue in the kernel as a linked
List of messages.

26

For every message queue in the system, the kernel maintains the following
structure of information:

#include<sys/types.h>
#include<sys/ipc.h> /*defines the ipc_perm structure */
Struct msqid_ds
{
Struct ipc_perm msg_perm; /*operation permission struct */
Struct msg *msg_first; /*ptr to first message on q*/
Struct msg *msg_last; /*ptr to last message on q*/
Ushort msg_cbytes; /*current #bytes on q*/
Ushort msg_qnum /* current # of messages on q */
Ushort msg_qbytes /*max # of bytes allowed on q */
Ushort msg_lspid /*pid of last msgend */
Ushort msg_lrpid; /* pid of last msgrcv */
Time_ t msg_stime; /*time of last msgend */
Time_t msg_rtime /* time of last msgrcv */
Time_t msg_ctime /*time of last msgct1
};

27

Msg_perm
structure

link
Msg_first
Type= 100

Msg_last Length=1

.. . . data

Msg_ctime

28

A new message queue is created, or an existing message queue is accessed
with the msgget system call.

#include<sys/ipc.h>
#include<sys/msg.h>

Int msgget ( key_t key, int msgflag );

The value returned by msgget is the message queue
identifier, msqid, or -1 if an error occurred.

msqid = identifies a particular queue of messages.
Flag argument specifies the low-order 9 bits of the mode for the
IPC channel.
29

Once a message queue is opened with msgget, we put a message on
the queue using the msgsnd system call.
Same header files as msgget.

Int msgsnd ( int msqid, struct msgbuf *ptr, int length, int flag) ;

Flag = the argument can be specified as either IPC_NOWAIT or as
zero.

30

A message is read from a message queue using the msgrcv system call.

Int msgrcv ( int msqid, struct msgbuf *ptr, int length, long msgtype,
int flag) ;

On successful return, msgrcv return the number of bytes of data in the
received message.

31

The msgctl system call provides a variety of control operations on a message queue.

Int msgctl ( int msqid, int cmd, struct msqid_ds *buff);

32

Multiplexing messages
By having a type associated with each message is to allow multiple
processes to multiplex messages on to a single queue.

By having the type of each message is to signify if the message is
from the client to the server, or vice versa.

A server with multiple clients.

Here we can use a type of 1, say, to indicate a message from any
client to the server.
If the client passes its process ID as part of the message, the server
can send its messages to the client processes, using the clients
process ID as the message type.

With message queues we can read the messages in any order that 33
is consistent with the values we associate with message types.

Semaphores
Semaphores are a synchronization primitive.

If we have one resource, say a file that is shared, then the valid
semaphore values are zero and one.

Semaphore is used to provide resource synchronization between
different processes, the actual semaphore value must be stored
in the kernel.

Process A Process B

Semaphore : 0 or 1

34
Semaphore value stored in kernel

To obtain a resource that is controlled by a semaphore, a process
needs to test its current value, and if the current value is greater
than zero, decrement the value by one.

0 = wait
1 = enter

If the current value is zero, the process must wait until the value it
greater than zero.

The system V implementation of semaphores is done in the kernel,
where it is possible to guarantee that a group of operations on a
semaphore is done atomically, with respect to other processes.

35

For every set of semaphores in the system, the kernel maintains the following
structure of information
#include<sys/types.h> /* defines the ipc_perm structure */
#include<sys/ipc.h>
Struct semid_ds {
Struct ipc_perm sem_perm; /*operation permission struct */
Struct sem *sem_base ; /*ptr to first semaphore in set */
Ushort sem_nsems; /* # of semaphore in set */
Time_ t sem_otime; /* time of last semop */
Time_t sem_ctiem; /*time of last change */
};

The sem structure is the internal data structure used by the kernel to maintain
the set of values for a given semaphore. Every member of a semaphore set is
described by the following structure :
Struct sem {
Ushort semval; /*semaphore value, nonnegative */
Short sempid; /* pid of last operation */
Ushort semncnt; /*# awaiting semval >cval */
Ushort semzcnt; /*# awaiting semval=0; */
36
};

A semaphore is created, or an existing semaphore is accessed with the semget
system call
#include<sys/ipc.h>
#include<sys/sem.h>
int semget(key_t key, int nsems, int semflag);
The value returned by semget is the semaphore identifier, semid, or -1 if an
error occurred.
Once a semaphore set is opened with semget, operations are performed on one
or more of the semaphore value in the set using the semop system call
#include<sys/ipc.h>
#include<sys/sem.h>
int semop(int semid, struct sembuf **opsptr, unsigned int nops);
The pointer opsptr points to an array of the following structers:
Struct sembuf {
ushort sem_ num ; /* semaphore # */
short sem_op;/* semaphore operation */
short sem_fig;/*operation flags */
};
37

The semct1 system call provides various control operations on a semaphore.
#include<sys/types.h>
#include<sys/ipc.h>
#include<sys/sem.h>
int semct1(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 IPC_GETALL & IPC_SETALL */
}arg;

38

Unit 7

Recommended

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Unit 7 (20)

More from vamsitricks (20)

Unit 7