0% found this document useful (0 votes)
22 views21 pages

Inter-Process Communication Overview

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views21 pages

Inter-Process Communication Overview

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd

Operating Systems

Inter-process Communication
Instructor: Dr. Huma Javed
Lecture: 07
Date: 6th February 2008
Inter-Process Communication
• A process has access to the memory which
constitutes its own address space.
• When a child process is created, the only way to
communicate between a parent and a child process is:
– The variables are replicas
– The parent receives the exit status of the child
• So far, we’ve discussed communication mechanisms
only during process creation/termination
• Processes may need to communicate during their life
time.
Cooperating Processes
• Independent process cannot affect or be affected by the
execution of another process.
• Cooperating process can affect or be affected by the
execution of another process
• Advantages of process cooperation
– Information sharing
– Computation speed-up:
• make use of multiple processing elements
– Modularity
– Convenience:
• editing, printing, compiling in parallel
• Dangers of process cooperation
– Data corruption, deadlocks, increased complexity
– Requires processes to synchronize their processing
Purposes for IPC
• IPC allows processes to communicate and
synchronize their actions without sharing the same
address space
– Data Transfer
– Sharing Data
– Event notification
– Resource Sharing and Synchronization
IPC Mechanisms
• Mechanisms used for communication and synchronization
– Message Passing
• message passing interfaces, mailboxes and
message queues
• sockets, pipes
– Shared Memory: Non-message passing systems
– Synchronization – primitives such as semaphores to
higher level mechanisms such as monitors
– Event Notification - UNIX signals
• We will defer a detailed discussion of synchronization
mechanisms and concurrency until a later class
• Here we want to focus on some common (and fundamental) IPC
mechanisms
Message Passing
• In a Message system there are no shared variables.
• IPC facility provides two operations for fixed or variable
sized message:
– send(message)
– receive(message)
• If processes P and Q wish to communicate, they need to:
– establish a communication link
– exchange messages via send and receive
• Implementation of communication link
– physical (e.g., memory, network etc)
– logical (e.g., syntax and semantics, abstractions)
Implementation Questions
• How are links established?
• Can a link be associated with more than two
processes?
• How are links made known to 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 Systems
• Exchange messages over a communication link
• Methods for implementing the communication link
and primitives (send/receive):
– Direct or Indirect communications (Naming)
– Symmetric or Asymmetric communications
(blocking versus non-blocking)
– Buffering
– Send-by-copy or send-by-reference
– fixed or variable sized messages
Direct Communication – Internet
and Sockets
• Processes must name each other explicitly:
– Symmetric Addressing
• send (P, message) – send to process P
• receive(Q, message) – receive from Q
– Asymmetric Addressing
• send (P, message) – send to process P
• receive(id, message) – rx from any; system sets id = sender
• Properties of communication link
– Links established automatically between pairs
– processes must know each others ID
– Exactly one link per pair of communicating processes
• Disadvantage: a process must know the name or ID of the
process(es) it wishes to communicate with
Indirect Communication
• Messages are sent to or received from mailboxes
(also referred to as ports).
– Each mailbox has a unique id.
– Processes can communicate only if they share a mailbox.
• Primitives:
– send(A, message) – send a message to mailbox A
– receive(A, message) – receive a message from mailbox A
• Properties of communication link
– Link established only if processes share a common
mailbox
– A link may be associated with more than 2 processes.
– Each pair of processes may share several communication
links.
Indirect Communication-
Ownership
• process owns (i.e. mailbox is implemented in user
space):
– only the owner may receive messages through this mailbox.
– Other processes may only send.
– When process terminates any “owned” mailboxes are
destroyed.
• kernel owns
– then mechanisms provided to create, delete, send and
receive through mailboxes.
– Process that creates mailbox owns it (and so may receive
through it)
– but may transfer ownership to another process.
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.
– OR allow only one process at a time to execute a receive
operation.
– OR 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 send:
• sender blocked until message received by mailbox or process
– nonblocking send:
• sender resumes operation immediately after sending
– blocking receive:
• receiver blocks until a message is available
– nonblocking receive:
• receiver returns immediately with either a valid or null message.
Buffering
• All messaging system require framework to
temporarily buffer messages.
• These queues are implemented in one of three
ways:
– Zero capacity
• No messages may be queued within the link, requires
sender to block until receiver retrieves message.
– Bounded capacity
• Link has finite number of message buffers. If no buffers are
available then sender must block until one is freed up.
– Unbounded capacity
• Link has unlimited buffer space, consequently send never
needs to block.
Client-Server Communication
• Sockets
• Remote Procedure Calls
• Remote Method Invocation (Java)
Sockets
• A socket is defined as an endpoint for
communication
• Concatenation of IP address and port
• The socket [Link]:1625 refers to port
1625 on host [Link]
• Communication consists between a pair of
sockets
Socket Communication
Remote Procedure Calls
• Remote procedure call (RPC) abstracts
procedure calls between processes on
networked systems.
• 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.
Execution of RPC
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.
Marshalling Parameters

Common questions

Powered by AI

Buffering in messaging systems allows for temporary storage of messages, facilitating communication between processes with different processing speeds . It can be implemented in three ways: zero capacity, which requires the sender to block until the receiver retrieves the message; bounded capacity, which allows a finite number of messages to be queued, blocking the sender when buffers are full; and unbounded capacity, which theoretically provides unlimited space and ensures the sender never blocks . The choice of buffering implementation directly affects system performance and synchronization between processes .

Remote procedure calls (RPC) abstract the procedure calls between processes on networked systems by using stubs as client-side proxies for the actual server procedure. The client-side stub locates the server and marshalls the parameters, while the server-side stub receives these parameters, unpacks them, and performs the procedure on the server . This abstraction simplifies complex networking details for the user, functioning similarly to local procedure calls even though they are executed over a network .

Message passing achieves synchronization through blocking and non-blocking operations. Blocking send ensures a sender is blocked until the message is received by a mailbox or process, and a blocking receive means the receiver is blocked until a message is available . Nonblocking operations allow the sender or receiver to continue processing immediately after performing send or receive operations, which can lead to varying degrees of synchronization effectiveness depending on implementation .

Sockets function as endpoints for communication in client-server architectures, facilitating data exchange between two networked systems. They consist of an IP address and port number, such as 161.25.19.8:1625, and communication occurs through a pair of sockets on the client and server computers. Sockets support various forms of communication, including point-to-point and broadcast, providing a versatile mechanism for network communication .

Asymmetric addressing in direct communication implies that a process can send a message to another process by addressing the recipient specifically, while when receiving, it can do so without specifying the sender. This system sets the sender ID when receiving a message, which simplifies the receiving process for multiple potential senders but requires knowing recipient IDs for sending . As a disadvantage, communication requires processes to know the ID of other processes they want to communicate with .

Mailboxes offer a structured way to implement indirect communication as they allow processes to communicate without needing to know each other’s identities, which enhances modularity and scalability . They can be associated with more than two processes, increasing flexibility. However, their limitations include potential complexity when managing mailbox ownership, as mailboxes must be managed efficiently to avoid resource leaks or unintentional termination of communication lines when processes terminate. Additionally, communication via mailboxes may introduce overhead compared to direct communication due to the need for additional management and control structures .

In direct communication, processes must name each other explicitly to send and receive messages, establishing a communication link automatically between pairs with exactly one link per pair of communicating processes . In contrast, indirect communication uses mailboxes to send or receive messages, allowing a link to be associated with more than two processes if they share the mailbox. Mailboxes have unique IDs, and the link is only established if processes share a common mailbox .

Issues from process cooperation include data corruption, deadlocks, and increased complexity . These can be managed through proper synchronization techniques to ensure data integrity, like using locks and semaphores to prevent race conditions. Deadlocks can be mitigated through strategies such as careful resource allocation, deadlock detection algorithms, and sometimes even avoiding resource sharing where not necessary. Complexity management requires modular design and thorough understanding of interdependencies within process interactions .

Potential solutions for the issue of multiple receivers in indirect communication include allowing a link to be associated with at most two processes, restricting with only one process at a time being able to execute a receive operation, or letting the system arbitrarily select the receiver, with the sender being notified about which receiver took the message . Each solution offers trade-offs in terms of complexity, scalability, and effectiveness in message delivery .

The advantages of process cooperation include information sharing, computation speed-up by using multiple processing elements, modularity, and convenience, such as editing, printing, and compiling in parallel . However, there are dangers that include data corruption, deadlocks, increased complexity, and the requirement for processes to synchronize their processing .

You might also like