Principles of

Operating Systems
Lecture 5 - Interprocess Communication
Ardalan Amiri Sani (ardalan@uci.edu)

[lecture slides contains some content adapted from : Silberschatz textbook authors]
 Interprocess Communication
● Processes within a system may be independent or cooperating
● Cooperating process can affect or be affected by other processes,
including sharing data
● Reasons for cooperating processes:
● Information sharing
● Computation speedup
● Modularity
● Convenience
● Cooperating processes need interprocess communication (IPC)
● Two models of IPC
● Shared memory
● Message passing
Interprocess Communication – Shared Memory

● An area of memory shared among the processes that wish

to communicate
● The communication is under the control of the processes
not the operating system.
● Major issues is to provide mechanism that will allow the
user processes to synchronize their actions when they
access shared memory.
● Synchronization is discussed in great details in Chapter 5.
Interprocess Communication – Shared Memory
 Producer-Consumer Problem
● Paradigm for cooperating processes, producer process
produces information that is consumed by a consumer
process
● unbounded-buffer places no practical limit on the size
of the buffer
● bounded-buffer assumes that there is a fixed buffer
size
 Bounded-Buffer – Shared-Memory Solution

● Shared data
#define BUFFER_SIZE 10
typedef struct {
. . .
} item;

item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
 Bounded-Buffer – Producer

item next_produced;
while (true) {
/* produce an item in next produced */
while (((in + 1) % BUFFER_SIZE) == out)
; /* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
}
Bounded Buffer – Consumer
item next_consumed;
while (true) {
while (in == out)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;

/* consume the item in next consumed */

}
 Bounded-Buffer – Shared-Memory Solution

● How many elements in the buffer can be used at most at a given time?

item next_produced; item next_consumed;

while (true) { while (true) {
while (in == out)
/* produce an item in next produced */
; /* do nothing */
while (((in + 1) % BUFFER_SIZE) == out)
next_consumed = buffer[out];
; /* do nothing */
out = (out + 1) % BUFFER_SIZE;
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE; /* consume the item in next
} consumed */
}

Producer Consumer
 Bounded-Buffer – Shared-Memory Solution

● Solution is correct, but can only use BUFFER_SIZE-1 elements

Interprocess Communication – Message Passing

● Mechanism for processes to communicate and to synchronize

their actions

● Message system – processes communicate with each other

without resorting to shared variables

● IPC facility provides two operations:

● send(message)
● receive(message)

● The message size is either fixed or variable

Interprocess Communication – Message Passing
 Message Passing (Cont.)

● If processes P and Q wish to communicate, they need to:

● Establish a communication link between them
● Exchange messages via send/receive
● Implementation issues:
● How are links established?
● Can a link be associated with more than two processes?
● How many links can there be between every pair of
communicating processes?
● What is the capacity of a link?
● Is the size of a message that the link can accommodate fixed or
variable?
● Is a link unidirectional or bi-directional?
 Message Passing (Cont.)

● Implementation of communication link

● Physical:
- Shared memory
- Hardware bus
- Network
● Logical:
- Direct or indirect
- Synchronous or asynchronous
- Automatic or explicit buffering
 Direct Communication
● Processes must name each other explicitly:
● send (P, message) – send a message to process P
● receive(Q, message) – receive a message from process Q
● Properties of communication link
● Links are established automatically
● A link is associated with exactly one pair of communicating
processes
● Between each pair there exists exactly one link
● The link may be unidirectional, but is usually bi-directional
 Indirect Communication

● Messages are directed and received from mailboxes (also referred

to as ports)
● Each mailbox has a unique id
● Processes can communicate only if they share a mailbox
● Properties of communication link
● Link established only if processes share a common mailbox
● A link may be associated with many processes
● Each pair of processes may share several communication links
● Link may be unidirectional or bi-directional
 Indirect Communication
● Operations
● create a new mailbox (port)
● send and receive messages through mailbox
● destroy a mailbox
● Primitives are defined as:
send(A, message) – send a message to mailbox A
receive(A, message) – receive a message from mailbox A
 Indirect Communication
● Mailbox sharing
● P1, P2, and P3 share mailbox A
● P1, sends; P2 and P3 receive
● Who gets the message?
● Solutions
● Allow a link to be associated with at most two
processes
● Allow only one process at a time to execute a receive
operation
● Allow the system to select arbitrarily the receiver.
Sender is notified who the receiver was.
 Synchronization
● Message passing may be either blocking or non-blocking
● Blocking is considered synchronous
● Blocking send -- the sender is blocked until the message is
received
● Blocking receive -- the receiver is blocked until a message
is available
● Non-blocking is considered asynchronous
● Non-blocking send -- the sender sends the message and
continue
● Non-blocking receive -- the receiver receives:
● A valid message, or
● Null message
● Different combinations possible
● If both send and receive are blocking, we have a rendezvous
 Message passing (Cont.)

● Producer-consumer becomes trivial

message next_produced;
while (true) {
/* produce an item in next produced */
send(next_produced); Producer
}

message next_consumed; Consumer

while (true) {
receive(next_consumed);

/* consume the item in next consumed */

}
 Buffering

● Queue of messages attached to the link.

● implemented in one of three ways
1. Zero capacity – no messages are queued on a link.
Sender must wait for receiver (rendezvous)
2. Bounded capacity – finite length of n messages
Sender must wait if link full
3. Unbounded capacity – infinite length
Sender never waits
 Examples of IPC Systems - POSIX

● POSIX Shared Memory

● Process first creates shared memory segment
shm_fd = shm_open(name, O CREAT | O RDWR, 0666);
● Also used to open an existing segment to share it
● Set the size of the object
ftruncate(shm fd, 4096);
● Now the process could write to the shared memory
sprintf(shared memory, "Writing to shared
memory");
IPC POSIX Producer
IPC POSIX Consumer
 Examples of IPC Systems - Mach
● Mach communication is message based
● Even system calls are messages
● Each task gets two mailboxes at creation- Kernel and Notify
● Only three system calls needed for message transfer
msg_send(), msg_receive(), msg_rpc()
● Mailboxes needed for communication, created via
port_allocate()
● Send and receive are flexible, for example four options if mailbox full:
- Wait indefinitely
- Wait at most n milliseconds
- Return immediately
- Temporarily cache a message
 Examples of IPC Systems – Windows

● Message-passing centric via advanced local procedure call

(LPC) facility
● Only works between processes on the same system
● Uses ports (like mailboxes) to establish and maintain
communication channels
● Communication works as follows:
- The client opens a handle to the subsystem’s
connection port object.
- The client sends a connection request.
- The server creates two private communication ports
and returns the handle to one of them to the client.
- The client and server use the corresponding port
handle to send messages or callbacks and to listen for
replies.
Local Procedure Calls in Windows
 Communications in Client-Server Systems

● Sockets
● Remote Procedure Calls
● Pipes
● Remote Method Invocation (Java)
 Sockets

● A socket is defined as an endpoint for communication

● Concatenation of IP address and port – a number included at

start of message packet to differentiate network services on a
host

● The socket 161.25.19.8:1625 refers to port 1625 on host

161.25.19.8

● Communication consists between a pair of sockets

● All ports below 1024 are well known, used for standard
services

● Special IP address 127.0.0.1 (loopback) to refer to system on

which process is running
Socket Communication
 Sockets in Java

● Three types of sockets

● Connection-oriented
(TCP)
● Connectionless (UDP)
● MulticastSocket
class– data can be sent
to multiple recipients

● Consider this “Date” server:

 Remote Procedure Calls
● Remote procedure call (RPC) abstracts procedure calls
between processes on networked systems
● Again uses ports for service differentiation
● Stubs – client-side proxy for the actual procedure on the
server
● The client-side stub locates the server and marshalls the
parameters
● The server-side stub receives this message, unpacks the
marshalled parameters, and performs the procedure on the
server
● On Windows, stub code compile from specification written in
Microsoft Interface Definition Language (MIDL)
 Remote Procedure Calls (Cont.)
● Data representation handled via External Data
Representation (XDL) format to account for different
architectures
● Big-endian and little-endian
● Remote communication has more failure scenarios than local
● Messages can be delivered exactly once rather than at
most once
● OS typically provides a rendezvous (or matchmaker) service
to connect client and server
Execution of RPC
 Pipes
● Acts as a conduit allowing two processes to communicate
● Ordinary pipes – cannot be accessed from outside the
process that created it. Typically, a parent process creates a
pipe and uses it to communicate with a child process that it
created.
● Named pipes – can be accessed without a parent-child
relationship.
 Ordinary Pipes

● Ordinary Pipes allow communication in standard producer-consumer

style
● Producer writes to one end (the write-end of the pipe)
● Consumer reads from the other end (the read-end of the pipe)
● Ordinary pipes are therefore unidirectional
● Require parent-child relationship between communicating processes

● Windows calls these anonymous pipes

● See Unix and Windows code samples in textbook
#define READ_END 0
Ordinary Pipes
#define WRITE_END 1 (see full example in the book)
int main (void)
{
char write_msg[BUFFER_SIZE] = “Greetings”;
char read_msg[BUFFER_SIZE];
int fd[2];
pid_t pid;

if (pipe(fd) == -1) {
/* handle error */
}

pid = fork();

if (pid < 0) {
/* handle error */
}

If (pid > 0) { /* parent process */

close(fd[READ_END]);
write(fd[WRITE_END], write_msg, strlen(write_msg) + 1);
close(fd[WRITE_END]);
} else { /* child process */
close(fd[WRITE_END]);
read(fd[READ_END], read_msg, BUFFER_SIZE);
printf(“read %s”, read_msg);
close(fd[READ_END]);
}
return 0;
}
 Named Pipes

● Named Pipes are more powerful than ordinary pipes

● Communication is bidirectional
● No parent-child relationship is necessary between the
communicating processes
● Several processes can use the named pipe for communication
● Provided on both UNIX and Windows systems