0% found this document useful (0 votes)
21 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
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 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
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