0% found this document useful (0 votes)
25 views

Lecture 03 InterprocessCommunication

The document discusses interprocess communication and different models of IPC including shared memory and message passing. It describes producer-consumer problems and solutions using both shared memory and message passing. It also discusses issues like synchronization, direct and indirect communication, and blocking vs non-blocking operations.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
25 views

Lecture 03 InterprocessCommunication

The document discusses interprocess communication and different models of IPC including shared memory and message passing. It describes producer-consumer problems and solutions using both shared memory and message passing. It also discusses issues like synchronization, direct and indirect communication, and blocking vs non-blocking operations.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 45

Operating Systems

Phan Xuan Hieu


Data Science & Knowledge Technology Lab
Faculty of IT, VNU-UET
[email protected]
Interprocess Communication
Materials
§ Textbook:
• A. Silberschatz, P. B. Galvin, and G. Gagne: Operating System Concepts,
10th edition, John Wiley & Sons, 2018.
• Chapter 3

§ Futher reading:
• A. S. Tanenbaum and H. Bos: Modern Operating Systems, 4th edition,
Pearson Prentice Hall, 2015.
• Chapter 2

3
Contents
§ Interprocess communication (IPC)
§ IPC in shared-memory systems
§ IPC in message-passing systems
§ Examples of IPC systems

4
Contents
§ Interprocess communication (IPC)
§ IPC in shared-memory systems
§ IPC in message-passing systems
§ Examples of IPC systems

5
Interprocess communication
§ Processes within a system may be independent or cooperating
§ Cooperating process can affect or be affected by other
processes, including 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
6
Communication models

Shared memory Message passing

7
Producer-consumer problem
§ Paradigm for cooperating processes:
• Producer process produces information that is consumed by a
consumer process

§ Two variations:
• Unbounded-buffer places no practical limit on the buffer size:
• Producer never waits
• Consumer waits if there is no data in the buffer to consume
• Bounded-buffer assumes that there is a fixed buffer size
• Producer must wait if the buffer is full
• Consumer waits if there is no data in the buffer to consume

8
Contents
§ Interprocess communication (IPC)
§ IPC in shared-memory systems
§ IPC in message-passing systems
§ Examples of IPC systems

9
IPC – shared memory
§ An area of memory shared among the processes that wish
to communicate
§ The communication is under the control of the user
processes, not the operating system
§ Major issue is to provide mechanism that will allow the
user processes to synchronize their actions when they
access shared memory
§ Synchronization is discussed in detailed in later lectures

10
Bounded-buffer shared-memory solution

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

item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;

§ Solution is correct, but can only use BUFFER_SIZE-1


elements

11
Producer process (shared memory)

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;

12
Consumer process (shared memory)

item next_consumed;

while (true) {
while (out == in); /* do nothing */

next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
/* consume the item in next consumed */
}

13
What about using all the buffer?
§ Suppose that we want a solution to the producer-
consumer problem that can use all the buffer.
§ We can do so by having an integer counter that keeps
track the current number of elements in the buffer.
§ Initially, counter is set to 0.
§ The integer counter is incremented by the producer
after it produces a new element.
§ The integer counter is decremented by the consumer
after it consumes an element.

14
Producer process

while (true) {
/* produce an item in next produced */

while (counter == BUFFER_SIZE);


/* do nothing */
buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;
counter++;

15
Consumer process

while (true) {
while (counter == 0); /* do nothing */
next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;


counter--;

/* consume the item in next consumed */


}

16
Race condition
§ counter++ could be implemented as
• register1 = counter
• register1 = register1 + 1
• counter = register1

§ counter-- could be implemented as


• register2 = counter
• register2 = register2 – 1
• counter = register2

§ Consider if execution interleaving with “counter = 5” initially:


• S0: producer executes register1 = counter (register1 = 5)
• S1: producer executes register1 = register1 + 1 (register1 = 6)
• S2: consumer executes register2 = counter (register2 = 5)
• S3: consumer executes register2 = register2 – 1 (register2 = 4)
• S4: producer executes counter = register1 (counter = 6)
• S5: consumer executes counter = register2 (counter = 4)

17
Race condition (cont.)
§ Why race condition?
§ How to deal with race condition?
Will be discussed in detailed in later lecture.

18
Contents
§ Interprocess communication (IPC)
§ IPC in shared-memory systems
§ IPC in message-passing systems
§ Examples of IPC systems

19
IPC – message passing
§ 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

20
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 pairs 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?
• If bi-directional: Is half-duplex or full-duplex?
21
Implementation of communication link
§ Physical:
• Shared memory
• Hardware bus
• Network

§ Logical:
• Direct or indirect
• Synchronous or asynchronous
• Automatic or explicit buffering

22
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

23
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

24
Indirect communication (cont.)
§ Operations
• Create a new mailbox (port)
• Send and receive messages through mailbox
• Delete a mailbox

§ Primitives are defined as:


• send(A, message): send a message to mailbox A
• receive(A, message): receive a message from mailbox A

25
Indirect communication (cont.)
§ 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.

26
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
27
Producer-consumer: message passing
§ Producer
message next_produced;
while (true) {
/* produce an item in next_produced */

send(next_produced);
}

§ Consumer
message next_consumed;
while (true) {
receive(next_consumed)

/* consume the item in next_consumed */


}
28
Buffering
§ Queue of messages attached to the link
§ Implemented in one of three ways
• Zero capacity: no messages are queued on a link.
Sender must wait for receiver (rendezvous)
• Bounded capacity: finite length of n messages
Sender must wait if link full
• Unbounded capacity: infinite length
Sender never waits

29
Contents
§ Interprocess communication (IPC)
§ IPC in shared-memory systems
§ IPC in message-passing systems
§ Examples of IPC systems

30
Pipes
§ Acts as conduit allowing two processes to communicate
§ 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

31
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


32
Example of ordinary pipe

33
Example of ordinary pipe (cont.)

34
Named pipes
§ Named pipes are more powerful than ordinary pipes
§ Communication is bidirectional.
§ Half-duplex on Unix/Linux and full-duplex on Windows
§ No parent-child relationship is necessary between the
communicating processes
§ Several processes can use the named pipe for
communicaton
§ Provided on both Unix and Windows system

35
36
Communications in client-server systems
§ Sockets
§ Remote procedure calls (RPCs)

37
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 refer 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 the process is running
38
Socket communication

39
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 in Java

40
Sockets in Java (cont.)
The equivalent Date client

41
Remote procedure calls (RPCs)
§ 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)
42
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

43
Execution of RPCs

44
Summary
§ Types of IPCs
§ Shared memory
• Shared buffer
• Producer-consumer problem
• Race condition

§ Message passing
• Direct vs. indirect communication
• Blocking vs. non-blocking

§ Examples of IPCs
• Pipes (ordinary vs. named pipe)
• Sockets
• Remote procedure calls (RPCs)
45

You might also like