660 likes | 901 Views
Advanced Operating Systems. Lecture 5: Interprocess Communication. University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani. How Processes communicate. Improving process communication to make systems more modular, scalable and flexable. References
E N D
Advanced Operating Systems Lecture 5: Interprocess Communication University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Distributed Operating Systems
How Processes communicate • Improving process communication to make systems more modular, scalable and flexable. • References • “improving IPC by Kernel Design”, by Jochen Liedtke. Distributed Operating Systems
Outline • Why IPC? • IPC mechanisms • Pipe, • Socket, • Shared memory • Message • RPC (Remote Procedure call) • Universal address space. • How improve IPC through kernel. Distributed Operating Systems
IPC Fundamentals • What is IPC? Mechanisms to transfer data between processes • To share resources • Client/server paradigms • Inherently distributed applications • Reusable software components • Other good software engineering reasons • Why is it needed? • Not all important procedures can be easily built in a single process • To make systems modular, flexible and scalable. • Critical for micro-kernel OS and distributed systems. Distributed Operating Systems
OS address space Private address space Private address space Process B Process A IPC from the OS Point of View • Each process has a private address space • Normally, no process can write to another process’s space • How to get important data from process A to process B? Distributed Operating Systems
Solutions to IPC • Fundamentally, two options 1. Support some form of shared address space • Shared memory 2. Use OS mechanisms to transport data from one address space to another • Files, messages, pipes, RPC • Shared memory • OS has job of setting it up and perhaps synchronizing But not transporting data • Messages, etc • OS involved in every IPC step • OS transports data Distributed Operating Systems
Ideal IPC Characteristics • Fast • Easy to use • Well defined synchronization model • Versatile • Easy to implement • Works remotely Distributed Operating Systems
IPC and Synchronization • Synchronization is a major concern for IPC • Allowing sender to indicate when data is transmitted • Allowing receiver to know when data is ready • Allowing both to know when more IPC is possible Distributed Operating Systems
IPC and Connections • IPC mechanisms can be connectionless or require connection • Connectionless IPC mechanisms require no preliminary setup • Connection IPC mechanisms require negotiation and setup before data flows • Sometimes much is concealed from user, though Distributed Operating Systems
Connectionless IPC • Data simply flows • Typically, no permanent data structures shared in OS by sender and receiver + Good for quick, short communication + less long-term OS overhead - Less efficient for large, frequent communications - Each communication takes more OS resources per byte Distributed Operating Systems
Connection-Oriented IPC • Sender and receiver pre-arrange IPC delivery details • OS typically saves IPC-related information for them • Advantages/disadvantages pretty much the opposites of connectionless IPC Distributed Operating Systems
Data Process B Process A IPC Through File System • Sender writes to a file • Receiver reads from it • But when does the receiver do the read? • Often synchronized with file locking or lock files • Special types of files can make file-based IPC easier Distributed Operating Systems
Message-Based IPC • Sender formats data into a formal message • With some form of address for receiver • OS delivers message to receiver’s message input queue (might signal too) • Receiver (when ready) reads a message from the queue • Sender might or might not block Distributed Operating Systems
Message-Based IPC Diagram OS Process B Process A Data sent from A to B B’s message queue Distributed Operating Systems
Procedure Call IPC • Interprocess communication uses same procedure call interface as intraprocess • Data passed as parameters • Information returned via return values • Complicated since destination procedure is in a different address space • Generally, calling procedure blocks till call returns Distributed Operating Systems
Procedure IPC Diagram main () { . call(); . . . } . . . server(); . . . Data as parameters Data as return values Process B Process A Distributed Operating Systems
main () { . x = 10 . . . } . . . print(x); . . . write variable x x: 10 read variable x Process B Process A Shared Memory IPC • Processes share a common piece of memory either physically or virtually • Communications via normal reads/writes • May need semaphores or locks • In or associated with the shared memory Distributed Operating Systems
Synchronizing in IPC • How do sending and receiving process synchronize their communications? • Many possibilities, based on which process block when • Blocking Send, Blocking Receive, Often called message rendezvous • Non-Blocking Send, Blocking Receive, Essentially, receiver is message-driven • Non-Blocking Send, Non-Blocking Receive, polling or interrupt for receiver Distributed Operating Systems
Addressing in IPC • How does the sender specify where the data goes? • The mechanism makes it explicit (shared memory or RPC) • Or, there are options: Direct Addressing • Sender specifies name of the receiving process using some form of unique process name • Receiver can either specify name of expected sender or take stuff from anyone • Indirect Addressing: Data is sent to queues, mailboxes, or some other form of shared data structure: Much more flexible than direct addressing Distributed Operating Systems
Duality in IPC Mechanisms • Many aspects of IPC mechanisms are duals of each other Which implies that these mechanisms have the same power • First recognized in context of messages vs. procedure calls At least, IPC mechanisms can be simulated by each other • Depends on model of computation And on philosophy of user • In particular cases, hardware or existing software may make one perform better Distributed Operating Systems
UNIX IPC Mechanisms • Different versions of UNIX introduced different IPC mechanisms • Pipes • Message queues • Semaphores • Shared memory • Sockets • RPC Distributed Operating Systems
Pipes • Only IPC mechanism in early UNIX systems (other than files) • Uni-directional • Unformatted • Uninterpreted • Interprocess byte streams • Accessed in file-like way Distributed Operating Systems
Pipe Details • One process feeds bytes into pipe • A second process reads the bytes from it • Potentially blocking communication mechanism • Requires close cooperation between processes to set up • Named pipes allow more flexibility Distributed Operating Systems
Pipes and Blocking • Writing more bytes than pipe capacity blocks the sender • Until the receiver reads some of them • Reading bytes when none are available blocks the receiver • Until the sender writes some • Single pipe can’t cause deadlock Distributed Operating Systems
UNIX Message Queues • Introduced in System V Release 3 UNIX Like pipes, but data organized into messages • Message component include: • Type identifier • Length • Data Distributed Operating Systems
Semaphores • Also introduced in System V Release 3 UNIX • Mostly for synchronization only • Since they only communicate one bit of information • Often used in conjunction with shared memory Distributed Operating Systems
UNIX Shared Memory • Also introduced in System V Release 3 • Allows two or more processes to share some memory segments • With some control over read/write permissions • Often used to implement threads packages for UNIX Distributed Operating Systems
Sockets • Introduced in 4.3 BSD • A socket is an IPC channel with generated endpoints • Great flexibility in it characteristics • Intended as building block for communication • Endpoints established by the source and destination processes Distributed Operating Systems
UNIX Remote Procedure Calls • Procedure calls from one address space to another • On the same or different machines • Requires cooperation from both processes • In UNIX, often built on sockets • Often used in client/server computing Distributed Operating Systems
Problems with Shared Memory • Synchronization • Protection • Pointers Distributed Operating Systems
Synchronization • Shared memory itself does not provide synchronization of communications • Except at the single-word level • Typically, some other synchronization mechanism is used • E.g., semaphore in UNIX • Events, semaphores, or hardware locks in Windows NT Distributed Operating Systems
Protection • Who can access a segment? And in what ways? • UNIX allows some read/write controls • Windows NT has general security monitoring based on the object-status of shared memory Distributed Operating Systems
a: __ b: __ z: __ y: 20 x: 10 w: 5 Process B Process A Pointers in Shared Memory • Pointers in a shared memory segment can be troublesome • For that matter, pointers in any IPC can be troublesome Distributed Operating Systems
A Troublesome Pointer a: __ b: __ z: __ y: 20 x: 10 w: 5 Process B Process A Distributed Operating Systems
How share pointers? • Copy-time translation • Locate each pointer within old version of the data Then translate pointers are required • Requires both sides to traverse entire structure • Not really feasible for shared memory • Reference-time translation • Encode pointers in shared memory segment as pointer surrogates,typically, as offsets into some other segment in separate contexts. So each sharer can have its own copy of what is pointed to • Slow, pointers in two formats • Pointer Swizzling • cache results in the memory location, only first reference is expensive • But each sharer must have his own copy • Must “unswizzle” pointers to transfer data outside of local context • Stale swizzled pointers can cause problems • All involve somehow translating pointers at some point before they are used Distributed Operating Systems
Shared Memory in a Wide Virtual Address Space • When virtual memory was created, 16 or 32 bit addresses were available • Reasonable size for one process • But maybe not for all processes on a machine • And certainly not for all processes ever on a machine Distributed Operating Systems
Implications of Single Shared Address Space • IPC is trivial • Shared memory, RPC • Separation of concepts of address space and protection domain • Uniform address space Distributed Operating Systems
Address Space and Protection Domain • A process has a protection domain • The data that cannot be touched by other processes • And an address space • The addresses it can generate and access • In standard systems, these concepts are merged Distributed Operating Systems
Uniform-Addressing Allows Easy Sharing • Any process can issue any address • So any data can be shared • All that’s required is changing protection to permit desired sharing • Suggests programming methods that make wider use of sharing Distributed Operating Systems
Windows NT IPC • Inter-thread communications • Within a single process • Local procedure calls • Between processes on same machine • Shared memory Distributed Operating Systems
Windows NT and Client/Server Computing • Windows NT strongly supports the client/server model of computing • Various OS services are built as servers, rather than part of the kernel • Windows NT needs facilities to support client/server operations • Which guide users to building client/server solution Distributed Operating Systems
Client/Server Computing and RPC • In client/server computing, clients request services from servers • Service can be requested in many ways • But RPC is a typical way • Windows NT uses a specialized service for single machine RPC Distributed Operating Systems
Local Procedure Call (LPC) • Similar in many ways to RPC, but optimized to only work on a single machine • Primarily used to communicate with protected subsystems • It also provides a true RPC facility • Application calls routine in an application programming interface Which is usually in a dynamically linked library Which sends a message to the server through a messaging mechanism Distributed Operating Systems
Windows NT LPC Messaging Mechanisms • Messages between port objects • Message pointers into shared memory • Using dedicated shared memory segments Distributed Operating Systems
Port Objects • Windows NT is generally object-oriented • Port objects support communications • Two types: • Connection ports • Used to establish connections between clients and servers • Named, so they can be located • Only used to set up communication ports • Communication ports • Used to actually pass data • Created in pairs, between given client and given server • Private to those two processes • Destroyed when communications end Distributed Operating Systems
Windows NT Port Example Connection port Server process Client process Distributed Operating Systems
Windows NT Port Example Connection port Server process Client process Distributed Operating Systems
Communication ports Windows NT Port Example Connection port Server process Client process Distributed Operating Systems
Send request Windows NT Port Example Connection port Communication ports Server process Client process Distributed Operating Systems
Message Passing through Port Object Message Queues • One of three methods in Windows NT to pass messages 1. Client submits message to OS 2. OS copies to receiver’s queue 3. Receiver copies from queue to its own address space Distributed Operating Systems