Interprocess Communication

Chapter 3
 Interprocess Communication
 Processes within a system may be independent or cooperating
 An independent process cannot affect or be affected by execution of
another process
 A cooperating process can affect or be affected by the execution of
another process

 Reasons for cooperating processes:

 Information sharing
 Computation speedup
 Modularity
 Convenience

 Cooperating processes need inter-process communication (IPC)

 Communications Models
 Two models of IPC
 Message passing
 Shared memory
 IPC – Shared Memory Model
 A region of memory shared among the processes that wish to communicate.

 The communication is under the control of the users processes not the OS.

 Used for large amount of data transfer.

 Major issues is to provide mechanism that allows the user processes to

synchronize their actions when they access shared memory.

 Mostly used in shared memory systems.

 IPC – Message Passing Model
 Message passing – process communication without resorting to shared
variables
 IPC facility provides two operations:
 send(message) – message size fixed or variable
 receive(message)

 If two processes wish to communicate, they need to:

 Establish a communication link between them
 Exchange messages via send/receive

 Several choices in communication link implementation

 Direct or indirect communication,
 Synchronous or asynchronous communication
 Automatic or explicit buffering

 Mostly used in distributed systems, for small amount of data transfer (fixed
or variable length messages) as it is time consuming
 Message Format
 Consists of header and body of the
message
 In UNIX: no ID, only message type
 Control Information
 What to do if run out of buffer space
 Sequence numbers
 Priority

 Queuing discipline: usually FIFO but

can also include priorities
 Implementation Questions
 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?

 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 direct 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
 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 – consider the following …
 P1, P2, and P3 share mailbox A
 P1, sends; P2 and P3 receive
 Who gets the message?

 Possible Solutions to avoid unpredictable behavior

 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 next_produced; message next_consumed;

while (true) { while (true) {
/* produce an item */ receive(next_consumed);
send(next_produced); /* consume the item */
} }
 Link Capacity – Buffering
 Regardless of how messages are exchanged between processes,
messages are queued

 Queuing can be implemented in one of three ways

1. Zero capacity – queue has maximum length of 0
Sender must wait (or block) until the receiver gets the message
2. Bounded capacity – queue has finite length of n messages
Sender must wait if link full
3. Unbounded capacity – queue has “infinite” length
Sender never waits
 Examples of IPC Systems – POSIX
 Process first creates shared memory segment
segment_id = shmget(IPC_PRIVATE, size, S_IRUSR | S_IWUSR);

 Process wanting access to that shared memory must attach to it

shared_memory = (char *) shmat(segment_id, NULL, 0);

 Now the process could write to the shared memory

sprintf(shared_memory, "Writing to shared memory");

 When done a process can detach the shared memory from its address space
shmdt(shared_memory);

 Now process can remove the shared memory segment

shmdt(shared_id, IPC_RMID, NULL);
 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()
 Examples of IPC Systems – Windows XP
 Message-passing centric via 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 XP
 Communications in Client-Server Systems
There are various mechanisms:

 Sockets (Internet)

 Remote Procedure Calls (RPCs)

 Pipes

 Remote Method Invocation (RMI, Java)

 Sockets
 A socket is defined as an endpoint for communication.
 Concatenation of IP address and port.
 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
 Remote Procedure Calls (RPCs)
 RPC abstracts a Local Procedure Call between processes on a networked
system.
 Stubs – client-side proxy for the actual procedure on the server.
 The client-side stub locates the server and marshals the parameters.
 The server-side stub receives this message, unpacks the marshalled
parameters, and performs the procedure on the server.
 Vice versa happens on the opposite direction.
 On Windows, stub code compile from specification written in Microsoft
Interface Definition Language (MIDL)
 Data representation handled via External Data Representation (XDL)
format to account for different architectures (Big-endian and little-endian)
Remote Procedure Call Mechanism
Execution of RPC
 Pipes
 Acts as a channel allowing two processes to communicate

 Some Issues:
 Is communication unidirectional or bidirectional?
 In the case of two-way communication, is it half or full-duplex?
 Must there exist a relationship (i.e. parent-child) between the
communicating processes?
 Can the pipes be used over a network?

 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

 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

 Remote Method Invocation
 Remote Method Invocation (RMI) is a Java mechanism similar to
RPCs.

 RMI allows a Java program on one machine to invoke a method on a

remote object.
(Un)Marshalling Parameters