Inter-process communication (IPC) is a set of methods for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC methods are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.
There are several reasons for providing an environment that allows process cooperation:
- Information sharing
- Speedup
- Modularity
- Convenience
- Privilege separation
IPC may also be referred to as inter-thread communication and inter-application communication.
The combination of IPC with the address space concept is the foundation for address space independence/isolation
• Processes can communicate through shared areas of memory
– the Mutual Exclusion problem and Critical Sections
• Semaphores - a synchronisation abstraction
• Monitors - a higher level abstraction
• Inter-Process Message Passing much more useful for information transfer
– can also be used just for synchronisation
– can co-exist with shared memory communication
• Two basic operations : send(message) and receive(message)
– message contents can be anything mutually comprehensible
» data, remote procedure calls, executable code etc.
– usually contains standard fields
» destination process ID, sending process ID for any reply
» message length
» data type, data etc.
• Fixed-length messages:
– simple to implement - can have pool of standard-sized buffers
» low overheads and efficient for small lengths
copying overheads if fixed length too long
– can be inconvenient for user processes with variable amount of data to pass
» may need a sequence of messages to pass all the data
» long messages may be better passed another way e.g. FTP
copying probably involved, sometimes multiple copying into kernel and out
• Variable-length messages:
– more difficult to implement - may need a heap with garbage collection
» more overheads and less efficient, memory fragmentation
– more convenient for user processes
• Communication links between processes
– not concerned with physical implementation e.g. shared memory, processor bus, network etc.
– rather with issues of its logical implementation
• Issues:
– how are links established?
– can a link be associated with more than two processes?
– how many links can there be between every pair of processes?
– what is the capacity of a link?
» i.e. buffer space and how much
– fixed v. variable length messages
– unidirectional v. bidirectional ?
» can messages flow in one or both directions between two linked processes
» unidirectional if each linked process can either send orreceive but not both and each link has at least one receiver process connected to it
• Naming of links - direct and indirect communications
• Direct:
– each process wanting to communicate must explicitly name the recipient or sender of the communication
– send and receive primitives defined:
send ( P, message ) : send a message to process P
receive ( Q, message ) : receive a message from process Q
– a link established automatically between every pair of processes that want to communicate
» processes only need to know each other’s identity
– link is associated with exactly two processes
– link is usually bidirectional but can be unidirectional
– Process A Process B
while (TRUE) { while (TRUE) {
produce an item receive ( A, item )
send ( B, item ) consume item
} }
while (TRUE) { while (TRUE) {
produce an item receive ( A, item )
send ( B, item ) consume item
} }
– Wide Variety of interprocess communication (IPC) mechanisms – e.g.,
» Pipes & streams
» Sockets & Messages
» Remote Procedure Call
» Shared memory
– OS dependent
– Depends on whether the communicating processes share all or part of an address space

• Communicate information from one process to another via primitives:
send(dest, &message)
receive(source, &message)
• Receiver can specify ANY
• Receiver can choose to block or not
• Applicable to multiprocessor and distributed systems
void Producer() {
while (TRUE) {
/* produce item */
build_message(&m, item);
send(consumer, &m); /* send message */
receive(consumer, &m); /* wait for ack */
}
}
void Consumer {
while(TRUE) {
receive(producer, &m);
/* receive message */
extract_item(&m, &item);
send(producer, &m); /* send ack */
/* consume item */
}
– send ( ) operation
• Synchronous
– Returns after data is sent
– Blocks if buffer is full
• Asynchronous
– Returns as soon as I/O started
– Done?
» Explicit check
» Signal
– Blocks if buffer is full
– receive () operation
• Sync.
– Returns if there is a message
– Blocks if not
• Async.
– Returns if there is a message
– Returns indication if no message
– Indirect Communication – mailboxes
– Messages are sent to a named area – mailbox
– Processes read messages from the mailbox
– Mailbox must be created and managed
– Sender blocks if mailbox is full
– Enables many-to-many communication
– Scrambled messages (checksum)
– Lost messages (acknowledgements)
– Lost acknowledgements (sequence no.)
– Process unreachable (down, terminates)
– Naming
– Authentication
– Performance (copying, message building)
No comments:
Post a Comment