Lecture 3.ppt of cs field using AI and machine management

1. 1
Interprocess Communications
Teacher: Dr Brekhna

2. 2
Interprocess Communications
-Exchange of data between two or more separate,
independent processes/threads.
-Operating systems provide facilities/resources for inter-
process communications (IPC), such as message queues,
semaphores, and shared memory.
-Distributed computing systems make use of these
facilities/resources to provide application programming
interface (API) which allows IPC to be programmed at a
higher level of abstraction. (e.g., send and receive)
-Distributed computing requires information to be exchanged
among independent processes.

3. Importance of IPC
Resource Sharing: Multiple processes can share resources like memory, files,
and devices.
Data Exchange: Processes can send and receive data, facilitating collaborative
tasks.
Synchronization: IPC helps in coordinating the execution of processes,
preventing conflicts when accessing shared resources.
Modularity: It allows the design of systems in a modular way, where processes
can be developed and tested independently.
3

4. 4
IPC – unicast and multicast
In distributed computing, two or more processes engage in
IPC using a protocol agreed upon by the processes. A
process may be a sender at some points during a protocol, a
receiver at other points.
When communication is from one process to a single other
process, the IPC is said to be a unicast, e.g., Socket
communication. When communication is from one process
to a group of processes, the IPC is said to be a multicast,
e.g., Publish/Subscribe Message model, a topic that we
will explore in a later chapter.

5. 5
Unicast vs. Multicast
P
2
P
1 P
1
P
2 P
3 P
4...
unicast multicast
m
m m m

6. 6
Process 1 Process 2
data
sender receiver
Interprocess Communications in Distributed
Computing

7. 7
Operations provided in an archetypal
Interprocess Communications API
•Receive ( [sender], message storage object)
•Connect (sender address, receiver address), for
connection-oriented communication.
•Send ( [receiver], message)
•Disconnect (connection identifier), for
connection-oriented communication.

8. 8
Interprocess Communication in basic HTTP
C 1 C 2
S 3 S 4
C 4
W e b se rve r
W e b browse r
a p ro ce s s
a n o pe r a ti o n
da t a fl o w
o p e r a t i o n s :
S 1: a c c e p t c o n n e c ti o n
S 2: r e c e i ve (r e q u e s t)
S 3: s e n d (re s p o n s e )
S 3: d i s co n n e c t
C 1: m a k e c o n n e cti o n
C 2: s e n d (r e q u e s t)
C 3: re ce i ve (re s p o n s e )
C 4: d i s co n n e ct
S 2
C 3
S 1
H TTP
re q u e s t
H TTP
re s p o n s e
Processing order: C1, S1, C2, S2, S3, C3, C4, S4
s4

9. 9
Event Synchronization
Interprocess communication may require that the
two processes synchronize their operations: one side
sends, then the other receives until all data has been
sent and received.
Ideally, the send operation starts before the receive
operation commences.
In practice, the synchronization requires system
support.

10. 10
Synchronous vs. Asynchronous
Communication
The IPC operations may provide the synchronization
necessary using blocking. A blocking operation issued by
a process will block further processing of the process
until the operation is fulfilled.
Alternatively, IPC operations may be asynchronous or
nonblocking. An asynchronous operation issued by a
process will not block further processing of the process.
Instead, the process is free to proceed with its processing,
and may optionally be notified by the system when the
operation is fulfilled.

11. 11
Synchronous send and receive
pro c e ss 1
r unni ng o n ho st 1
b lo c k in g s en d s tar ts
b lo c k in g s en d retu rn s
b lo c k in g r ec eiv e s tar ts
b lo c k in g r ec eiv e en d s
ex ec u tio n f lo w
s u s p en d ed p er io d
Sync hr o no us Se nd and R e c e i ve
an o p e ratio n
ac k n o w led g e m en t o f d ata r ec eiv ed
p r o v id ed b y th eI P C fa c ility
pr o c e ss 2
r unni ng o n ho st 2
Client Server
Sender Receiver
Event Diagram

12. 12
Asynchronous send and synchronous
receive
P ro cess 1
P ro cess 2
b lo c k in g rec eiv e s tar ts
b lo c k in g rec eiv e retu rn s
ex ec u tio n flo w
s u s p en d ed p erio d
Asynchro no us Send and
Synchro no us R ecei ve
n o n b lo c k in g s en d
o p er atio n
Event Diagram
Client Server
Sender Receiver

13. 13
Synchronous send and Async. Receive - 1
P ro c e ss 1
P r o cess 2
n o n b lo c k in g r ec eiv e is s u ed
ex ec u tio n f lo w
s u s p en d ed p er io d
Sync hro no us Se nd and
Async hro no us R ec e i ve
b lo c k in g s en d is s u ed
S ce n a rio A
tr an s p ar en t ac k n o w led g em en t
p r o v id ed b y th eI P C f ac ility
Data from P1 was received by P2
before issuing a non-blocking receive op in P2

14. 14
Synchronous send and Async. Receive - 2
in d ef in ite
b lo c k in g
P ro cess 1
P ro cess 2
n o n b lo c k in g r ec eiv e is s u ed
an d r etu r n ed im m ed iately
ex ec u tio n f lo w
s u s p en d ed p erio d
Synchro no us Send and
Asynchro no us R ecei ve
b lo c k in g s en d is s u ed
S ce n a rio B
P ro cess 1
P ro cess 2
Data from P1 arrived to P2 after P2 issued a
non-blocking receive op

15. 15
Synchronous send and Async. Receive - 3
P ro c ess 1
P ro c e ss 2
n o n b lo c k in g r ec eiv e is s u ed
an d r etu r n ed im m ed iately
ex ec u tio n f lo w
s u s p en d ed p er io d
Sync hro no us Se nd and
Asynchro no us R e ce i ve
b lo c k in g s en d is s u ed
S ce n a rioC
p r o c es s is n o tified
o f th e ar r iv al o f
d ata
tr an s p ar en t ac k n o w led g em en t
p r o v id ed b y th eI P C f ac ility
Data from P1 arrived to P2 before P2 issues a non-blocking
receive op. P2 is notified of the arrival of data

16. 16
Asynchronous send and Asynchronous
receive
P ro c ess 1
P ro ce ss 2
n o n b lo c k in g r ec eiv e is s u ed
an d r e tu r n e d im m ed ia tely
e x ec u tio n f lo w
s u s p en d ed p er io d
Asynchro no us Se nd and
Asynchro no us R e c ei ve
b lo c k in g s en d is s u ed
S ce n a rioC
p r o c es s is n o tif ie d
o f th e ar r iv a l o f
d ata
Does P1 need an acknowledgement from P2?

17. 17
Event diagram
Pro ce s s A
Pro ce s s B
in terproc es s c om m unic ation
ex ec utio n flow
proc es s bloc k ed
Event diagram for a protocol
req ues t 1
res p ons e 1
res po ns e2
requ es t 2
tim e
Synchronous send and receive

18. 18
Blocking, deadlock, and timeouts
Blocking operations issued in the wrong sequence can cause
deadlocks.
Deadlocks should be avoided. Alternatively, timeout can be used to
detect deadlocks.
rec eive from proc es s 2 is s u ed
rec eived from proc es s 1 is s ued
pro c es s 1 bloc ked p en ding data
from proc es s 2.
proc es s 2 bloc ked pend in g data
from p roc es s 1.
P roc es s 1 P roc es s 2
P1 is waiting for P2’s data; P2 is waiting for P1’s data.

19. 19
Using threads for asynchronous IPC
When using an IPC programming interface, it is important to note
whether the operations are synchronous or asynchronous.
If only blocking operation is provided for send and/or receive, then it is
the programmer’s responsibility to using child processes or threads if
asynchronous operations are desired.
proce s s
m ain thread
new th read is s u es a blo c kingIP C o p eratio n
thread is blo c ked
thread is u nb loc k ed after the operatio n is fulfilled
m ain thread c o n tinu es w ith
oth er pro c es s in g

20. 20
Deadlocks and Timeouts
Connect and receive operations can result in indefinite
blocking
For example, a blocking connect request can result in the
requesting process to be suspended indefinitely if the
connection is unfulfilled or cannot be fulfilled, perhaps as a
result of a breakdown in the network .
It is generally unacceptable for a requesting process to
“hang” indefinitely. Indefinite blocking can be avoided by
using timeout.
Indefinite blocking may also be caused by a deadlock

21. 21
Indefinite blocking due to a deadlock
" re ce ive from proce ss 2" issu e d;
" re ce ive from proce ss 1" issu e d;
proce ss 1 block e d pe n din g data
from proce ss 2.
proce ss 2 block e d pe n din g data
from proce ss 1.
Proce s s 1 Proce ss 2
p ro ce s s
e x e c u t i n g
p ro ce s s
b l o ck e d
a n o p e r a t i o n
P1 is waiting for P2’s data; P2 is waiting for P1’s data.

22. Types of IPC
IPC can be classified into several categories based on the method of communication:
a. Message Passing
Description: Processes communicate by sending and receiving messages. This can be
done directly or through a message queue.
Mechanisms:
Direct Communication: Processes must explicitly name each other.
Indirect Communication: Messages are sent to a shared mailbox or queue.
Advantages: Simple and effective for small, distributed systems.
Disadvantages: Can incur overhead due to message copying and can be slower than
other methods.
22

23. Mechanisms and APIs for Message
Passing
Various programming languages and operating systems provide APIs for
implementing message passing:
•POSIX Message Queues: this mechanism is widely adopted in Unix-like
operating systems, including Linux for message passing. Support
synchronous and asynchronous communication.
•MPI (Message Passing Interface): is a standardized and portable
message-passing system designed to facilitate communication between
processes in parallel computing. MPI is widely used in high-performance
computing (HPC) environments and is essential for developing applications
that run on distributed systems, clusters, and supercomputers.
•ZeroMQ: A high-performance asynchronous messaging library that
provides socket-style communication.
23

24. b. Shared Memory
Shared memory is a method of inter-process communication (IPC) that allows multiple
processes to access a common memory space. This technique is widely used in
concurrent programming to enable fast data exchange and coordination between
processes, as it eliminates the overhead associated with message passing
Mechanisms:
Memory Mapping: Mapping a file or segment of memory into the process's
address space.
Synchronization Primitives: Semaphores, mutexes, or monitors are used to
manage access to shared memory.
Advantages: Fast communication, as processes can directly access memory.
Disadvantages: Complexity in synchronizing access and managing memory.
24

25. c. Pipes
Description: A unidirectional communication channel that allows
data to flow from one process to another.
Types:
Anonymous Pipes: Used for communication between parent and
child processes.
Named Pipes (FIFOs): Can be used between unrelated processes.
Advantages: Simple to use for linear data flows.
Disadvantages: Limited to one-way communication and can be
cumbersome for complex interactions.
25

26. d. Sockets
Description: A method for communication between processes over a network.
Types:
Stream Sockets (TCP): Provide reliable, connection-oriented communication.
–Use Cases: Web servers, email clients, file transfer applications.
Datagram Sockets (UDP): Offer connectionless communication with no
guarantee of delivery.
–Use Cases: Video streaming, online gaming
Advantages: Suitable for distributed systems and allows communication over
different machines.
Disadvantages: Higher overhead compared to local IPC methods.
26

27. e. Synchronization Mechanisms
IPC often requires synchronization to prevent race conditions
and ensure data consistency. Common synchronization
methods include:
Mutexes: Provide exclusive access to a resource for one
process at a time.
Semaphores: Allow multiple processes to access a limited
number of resources.
Condition Variables: Enable processes to wait for certain
conditions to be met before proceeding.
27

28. Applications of IPC
Client-Server Models: Used in web applications where
clients communicate with a server to request resources.
Distributed Systems: Processes on different machines
communicate via IPC mechanisms like sockets.
Multimedia Applications: Processes handling audio and
video streams often use IPC to synchronize data flow.
Operating System Services: Kernel and user processes
communicate to manage resources and services.
28

29. Challenges in IPC
Complexity: Designing an efficient IPC system can be
complex, especially with synchronization.
Overhead: Different IPC mechanisms come with varying
degrees of overhead which can impact performance.
Deadlocks: Improper management of resources can lead to
deadlocks, where processes are stuck waiting for each other.
29

30. END
30