Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Mobile operating system wikipedia , lookup
Copland (operating system) wikipedia , lookup
Plan 9 from Bell Labs wikipedia , lookup
Library (computing) wikipedia , lookup
Burroughs MCP wikipedia , lookup
Security-focused operating system wikipedia , lookup
Process management (computing) wikipedia , lookup
Unix security wikipedia , lookup
Advanced Operating Systems Lecture 5: Interprocess Communication University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Univ. of Tehran Distributed Operating Systems 1 How Processes communicate Some general guides. References Univ. of Tehran Distributed Operating Systems 2 Outline Why IPC Univ. of Tehran Distributed Operating Systems 3 IPC Fundamentals What is IPC? Mechanisms to transfer data between processes Why is it needed? Not all important procedures can be easily built in a single process Univ. of Tehran Distributed Operating Systems 4 Why do processes communicate? To share resources Client/server paradigms Inherently distributed applications Reusable software components Other good software engineering reasons Univ. of Tehran Distributed Operating Systems 5 The Basic Concept of IPC A sending process needs to communicate data to a receiving process Sender wants to avoid details of receiver’s condition Receiver wants to get the data in an organized way Univ. of Tehran Distributed Operating Systems 6 IPC from the OS Point of View Private address space Private address space OS address space Process B Process A Univ. of Tehran Distributed Operating Systems 7 Fundamental IPC Problem for the OS 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? Univ. of Tehran Distributed Operating Systems 8 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 Univ. of Tehran Distributed Operating Systems 9 Differences in Treatment of IPC Shared memory OS has job of setting it up And perhaps synchronizing But not transporting data Messages, etc OS involved in every IPC OS transports data Univ. of Tehran Distributed Operating Systems 10 Desirable IPC Characteristics Fast Easy to use Well defined synchronization model Versatile Easy to implement Works remotely Univ. of Tehran Distributed Operating Systems 11 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 Univ. of Tehran Distributed Operating Systems 12 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 Univ. of Tehran Distributed Operating Systems 13 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 Univ. of Tehran Distributed Operating Systems 14 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 Univ. of Tehran Distributed Operating Systems 15 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 Univ. of Tehran Distributed Operating Systems 16 File IPC Diagram Process A Univ. of Tehran Data Distributed Operating Systems Process B 17 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 Univ. of Tehran Distributed Operating Systems 18 Message-Based IPC Diagram OS Process A Univ. of Tehran Data sent from A to B B’s message queue Distributed Operating Systems Process B 19 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 Univ. of Tehran Distributed Operating Systems 20 File IPC Diagram main () { . call(); . . . Data as parameters Data as return values . . . server(); . . . } Process B Process A Univ. of Tehran Distributed Operating Systems 21 Shared Memory IPC Different 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 Univ. of Tehran Distributed Operating Systems 22 Shared Memory IPC Diagram main () { . x = 10 . . . write variable x x: 10 read variable x . . . print(x); . . . } Process B Process A Univ. of Tehran Distributed Operating Systems 23 Synchronizing in IPC How do sending and receiving process synchronize their communications? Many possibilities Based on which process block when Examples that follow in message context, but more generally applicable Univ. of Tehran Distributed Operating Systems 24 Blocking Send, Blocking Receive Both sender and receiver block Sender blocks till receiver receives Receiver blocks until sender sends Often called message rendezvous Univ. of Tehran Distributed Operating Systems 25 Non-Blocking Send, Blocking Receive Sender issues send, can proceed without waiting to discover fate of message Receiver waits for message arrival before proceeding Essentially, receiver is message-driven Univ. of Tehran Distributed Operating Systems 26 Non-Blocking Send, NonBlocking Receive Neither party blocks Sender proceeds after sending message Receiver works until message arrives Either receiver periodically checks in nonblocking fashion Or some form of interrupt delivered Univ. of Tehran Distributed Operating Systems 27 Addressing in IPC How does the sender specify where the data goes? In some cases, the mechanism makes it explicit (e.g., shared memory and RPC) In others, there are options Univ. of Tehran Distributed Operating Systems 28 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 Univ. of Tehran Distributed Operating Systems 29 Indirect Addressing Data is sent to queues, mailboxes, or some other form of shared data structure Receiver performs some form of read operations on that structure Much more flexible than direct addressing Univ. of Tehran Distributed Operating Systems 30 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 Univ. of Tehran Distributed Operating Systems 31 So which IPC mechanism to build/choose/use? Depends on model of computation And on philosophy of user In particular cases, hardware or existing software may make one perform better Univ. of Tehran Distributed Operating Systems 32 Typical UNIX IPC Mechanisms Different versions of UNIX introduced different IPC mechanisms Pipes Message queues Semaphores Shared memory Sockets RPC Univ. of Tehran Distributed Operating Systems 33 Pipes Only IPC mechanism in early UNIX systems (other than files) Uni-directional Unformatted Uninterpreted Interprocess byte streams Accessed in file-like way Univ. of Tehran Distributed Operating Systems 34 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 Univ. of Tehran Distributed Operating Systems 35 Pipes and Blocking Writing more bytes than pipe capacity blocks the sender Reading bytes when none are available blocks the receiver Until the receiver reads some of them Until the sender writes some Single pipe can’t cause deadlock Univ. of Tehran Distributed Operating Systems 36 UNIX Message Queues Introduced in System V Release 3 UNIX Like pipes, but data organized into messages Message component include: Type identifier Length Data Univ. of Tehran Distributed Operating Systems 37 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 Univ. of Tehran Distributed Operating Systems 38 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 Univ. of Tehran Distributed Operating Systems 39 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 Univ. of Tehran Distributed Operating Systems 40 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 Univ. of Tehran Distributed Operating Systems 41 Problems with Shared Memory Synchronization Protection Pointers Univ. of Tehran Distributed Operating Systems 42 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 Univ. of Tehran Distributed Operating Systems 43 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 Univ. of Tehran Distributed Operating Systems 44 Pointers in Shared Memory Pointers in a shared memory segment can be troublesome For that matter, pointers in any IPC can be troublesome Univ. of Tehran Distributed Operating Systems 45 Shared Memory Containing Pointers a: __ z: __ b: __ y: 20 x: 10 w: 5 Process B Process A Univ. of Tehran Distributed Operating Systems 46 A Troublesome Pointer a: __ z: __ b: __ y: 20 x: 10 w: 5 Process B Process A Univ. of Tehran Distributed Operating Systems 47 So, how do you share pointers? Several methods are in use Copy-time translation Reference-time translation Pointer Swizzling All involve somehow translating pointers at some point before they are used Univ. of Tehran Distributed Operating Systems 48 Copy-Time Pointer Translation When a process sends data containing pointers to another process 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 Univ. of Tehran Distributed Operating Systems 49 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 Univ. of Tehran Distributed Operating Systems 50 Pointer Swizzling Like reference-time, but 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 Univ. of Tehran Distributed Operating Systems 51 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 Univ. of Tehran Distributed Operating Systems 52 Wide Address Space Architectures Computer architects can now give us 64bit virtual addresses A 64-bit address space, consumed at 100 MB/sec, lasts 5000 years Orders of magnitude beyond any process’s needs 40 bits can address a TB Univ. of Tehran Distributed Operating Systems 53 Do we care? Should OS designers care about wide address space? Well, what can we do with them? One possible answer: Put all processes in the same address space Maybe all processes for all time? Univ. of Tehran Distributed Operating Systems 54 Implications of Single Shared Address Space IPC is trivial Shared memory, RPC Separation of concepts of address space and protection domain Uniform address space Univ. of Tehran Distributed Operating Systems 55 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 Univ. of Tehran Distributed Operating Systems 56 Separating Concepts These concepts are potentially orthogonal Just because you can issue an address doesn’t mean you can access it (Though clearly to access an address you must be able to issue it) Existing hardware can support this separation Univ. of Tehran Distributed Operating Systems 57 Context-Independent Addressing Addresses mean the same thing in any execution context So, a given address always refers to the same piece of data Key concept of uniform-address systems Allows many OS optimizations/improvements Univ. of Tehran Distributed Operating Systems 58 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 Univ. of Tehran Distributed Operating Systems 59 To Opal System New OS using uniform-addressing Developed at University of Washington Not intended as slight alteration to existing UNIX system Most of the rest of material specific to Opal Univ. of Tehran Distributed Operating Systems 60 Protection Mechanisms for Uniform-Addressing Protection domains are assigned portions of the address space They can allow other protection domains to access them Read-only Transferable access permissions System-enforced page-level locking Univ. of Tehran Distributed Operating Systems 61 Program Execution in Uniform-Access Memory Executing a program creates a new protection domain The new domain is assigned an unused portion of the address space But it may also get access to used portions E.g., a segment containing the required executable image Univ. of Tehran Distributed Operating Systems 62 Virtual Segments Global address space is divided into segments Each composed of variable number of contiguous virtual pages Domains can only access segments they attach to Attempting to access unattached segment causes a segment fault Univ. of Tehran Distributed Operating Systems 63 Persistent Memory in Opal Persistent segments exist even when attached to no current domain Recoverable segments are permanently stored And can thus survive crashes All Opal segments can be persistent and recoverable Pointers can thus live forever on disk Univ. of Tehran Distributed Operating Systems 64 Code Modules in Opal Executable code stored in modules Pure modules can be easily shared Independent of protection domains Because they are essentially static Can get benefit of dynamic loading without run-time linking Univ. of Tehran Distributed Operating Systems 65 Address Space Reclamation Trivial in non-uniform-address systems Tricky in uniform-address systems Problem akin to reclaiming i_nodes in the presence of hard links But even if segments improperly reclaimed, only trusting domains can be hurt Univ. of Tehran Distributed Operating Systems 66 Windows NT IPC Inter-thread communications Local procedure calls Within a single process Between processes on same machine Shared memory Univ. of Tehran Distributed Operating Systems 67 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 Univ. of Tehran Distributed Operating Systems 68 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 Univ. of Tehran Distributed Operating Systems 69 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 Windows NT also provides a true RPC facility for genuinely distributed computing Univ. of Tehran Distributed Operating Systems 70 Basic Flow of Control in Windows NT LPC 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 Univ. of Tehran Distributed Operating Systems 71 Windows NT LPC Messaging Mechanisms Messages between port objects Message pointers into shared memory Using dedicated shared memory segments Univ. of Tehran Distributed Operating Systems 72 Port Objects Windows NT is generally object-oriented Port objects support communications Two types: Connection ports Communication ports Univ. of Tehran Distributed Operating Systems 73 Connection Ports Used to establish connections between clients and servers Named, so they can be located Only used to set up communication ports Univ. of Tehran Distributed Operating Systems 74 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 Univ. of Tehran Distributed Operating Systems 75 Windows NT Port Example Connection port Server process Client process Univ. of Tehran Distributed Operating Systems 76 Windows NT Port Example Connection port Server process Client process Univ. of Tehran Distributed Operating Systems 77 Windows NT Port Example Connection port Communication ports Server process Client process Univ. of Tehran Distributed Operating Systems 78 Windows NT Port Example Connection port Send request Communication ports Server process Client process Univ. of Tehran Distributed Operating Systems 79 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 Univ. of Tehran Distributed Operating Systems 80 Characteristics of Message Passing via Queues Two message copies required Fixed-sized, fairly short message Port objects stored in system memory ~256 bytes So always accessible to OS Fixed number of entries in message queue Univ. of Tehran Distributed Operating Systems 81 Message Passing Through Shared Memory Used for messages larger than 256 bytes Client must create section object Shared memory segment Of arbitrary size Message goes into the section Pointer to message sent to receiver’s queue Univ. of Tehran Distributed Operating Systems 82 Setting up Section Objects Pre-arranged through OS calls Using virtual memory to map segment into both sender and receiver’s address space If replies are large, need another segment for the receiver to store responses OS doesn’t format section objects Univ. of Tehran Distributed Operating Systems 83 Characteristics of Message Passing via Shared Memory Capable of handling arbitrarily large transfers Sender and receiver can share a single copy of data i.e., data copied only once Requires pre-arrangement for section object Univ. of Tehran Distributed Operating Systems 84 Server Handling of Requests Windows NT servers expect requests from multiple clients Typically, they have multiple threads to handle requests Must be sufficiently general to handle many different ports and section objects Univ. of Tehran Distributed Operating Systems 85 Message Passing Through Quick LPC Third way to pass messages in Windows NT Used exclusively with Win32 subsystem Like shared memory, but with a key difference Dedicated resources Univ. of Tehran Distributed Operating Systems 86 Use of Dedicated Resources in Quick LPC To avoid overhead of copying Notification messages to port queue And thread switching overhead Client sets up dedicated server thread only for its use Also dedicated 64KB section object And event pair object for synchronization Univ. of Tehran Distributed Operating Systems 87 Characteristics of Message Passing via Quick LPC Transfers of limited size Very quick Minimal copying of anything Wasteful of OS resources Univ. of Tehran Distributed Operating Systems 88 Shared Memory in Windows NT Similar in most ways to other shared memory services Windows NT runs on multiprocessors, which complicates things Done through virtual memory Univ. of Tehran Distributed Operating Systems 89 Section Views Given process might not want to waste lots of its address space on big sections So a process can have a view into a shared memory section Different processes can have different views of same section Or multiple views for single process Univ. of Tehran Distributed Operating Systems 90 Shared Memory View Diagram view 1 view 2 Section view 3 Process B Process A Physical memory Univ. of Tehran Distributed Operating Systems 91 Improving IPC IPC performance is vital for new, specially microkernel based OS. IPC improves Modularity Flexibility Security Scalability Vital for Distributed system. On L3 OS, which is based on microkernel Reduced IPC to 5 us from 100. Univ. of Tehran Distributed Operating Systems 92 Improving IPC (2) On L3, all interactions with outside are based on IPC and through message. Everything is implemented as user level and accessed through IPC. Implemented on an Intel machine with 50 MHz, with TLB 32 entries. A null IPC Thread A (user mode) Kernel: Access thread B Thread B (user mode) Load id of B Set msg length to 0 switch stack pointer Call Kernel load id of A inspect received msg switch addr space return to user Univ. of Tehran Distributed Operating Systems 93 Improving IPC (3) The minimum, omitting everything, takes 20 instruction, 172 cycles (3.5 us). The aim was to reach 7 us for IPC, in practice 5us. Univ. of Tehran Distributed Operating Systems 94 Improving IPC (Solutions) System calls Reduced sys calls for IPC It is around 2 us Implement call (for sending message and waiting for response) and reply & wait (for receiver) Messages Combine a sequence of send operation: avoid several address space switches. Univ. of Tehran Distributed Operating Systems 95 Improving IPC (Solutions) Message transfer Avoid copying, in general user A space -> kernel space -> user B space Copying n bytes takes 20+ 0.7n cycles + TLB and cache miss Solution: shared buffer Security Many clients, shared buffer can be bottleneck Not variable to variable transfer. Explicit opening of comm. Channels. Univ. of Tehran Distributed Operating Systems 96 Improving IPC (Solutions) Alternative Solution: temporary mapping of address spaces. Avoid region crossing Put all Thread Control Blocks (tcbs) in a large virtual array such that the address can be calculated from thread ID. Use Double linked list for queues hold in tcbs Between %50-%80 of msg are short. Transfer short message through registers. Reduce cache miss by putting relvant codes and data in one pages. Univ. of Tehran Distributed Operating Systems 97 Next Lecture Scheduling References Univ. of Tehran Distributed Operating Systems 98