interprocess communications continued

Download Interprocess Communications Continued

Post on 14-Jan-2016

29 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Interprocess Communications Continued. Andy Wang COP 5611 Advanced Operating Systems. Outline. Shared memory IPC Shared memory and large address spaces Windows NT IPC Mechanisms. Shared Memory. A simple and powerful form of IPC Most multiprogramming OS’s use some form of shared memory - PowerPoint PPT Presentation

TRANSCRIPT

  • Interprocess Communications ContinuedAndy WangCOP 5611Advanced Operating Systems

  • OutlineShared memory IPCShared memory and large address spacesWindows NT IPC Mechanisms

  • Shared MemoryA simple and powerful form of IPCMost multiprogramming OSs use some form of shared memory E.g., sharing executablesNot all OSs make shared memory available to applications

  • Shared Memory DiagramProcess AProcess Bx: 10y: 20z: __a: __b: __

  • Problems with Shared MemorySynchronizationProtectionPointers

  • SynchronizationShared memory itself does not provide synchronization of communicationsExcept at the single-word levelTypically, some other synchronization mechanism is usedE.g., semaphore in UNIXEvents, semaphores, or hardware locks in Windows NT

  • ProtectionWho can access a segment? And in what ways?UNIX allows some read/write controlsWindows NT has general security monitoring based on the object-status of shared memory

  • Pointers in Shared MemoryPointers in a shared memory segment can be troublesomeFor that matter, pointers in any IPC can be troublesome

  • Shared Memory Containing PointersProcess AProcess Bx: 10y: 20z: __a: __b: __w: 5

  • A Troublesome PointerProcess AProcess Bx: 10y: 20z: __a: __b: __w: 5

  • So, how do you share pointers?Several methods are in useCopy-time translationReference-time translationPointer SwizzlingAll involve somehow translating pointers at some point before they are used

  • Copy-Time Pointer TranslationWhen a process sends data containing pointers to another processLocate each pointer within old version of the dataThen translate pointers are requiredRequires both sides to traverse entire structureNot really feasible for shared memory

  • Reference-Time TranslationEncode pointers in shared memory segment as pointer surrogatesTypically as offsets into some other segment in separate contextsSo each sharer can have its own copy of what is pointed toSlow, pointers in two formats

  • Pointer SwizzlingLike reference-time, but cache results in the memory locationOnly first reference is expensiveBut each sharer must have his own copyMust unswizzle pointers to transfer data outside of local contextStale swizzled pointers can cause problems

  • Shared Memory in a Wide Virtual Address SpaceWhen virtual memory was created, 16 or 32 bit addresses were availableReasonable size for one processBut maybe not for all processes on a machineAnd certainly not for all processes ever on a machine

  • Wide Address Space ArchitecturesComputer architects can now give us 64-bit virtual addressesA 64-bit address space, consumed at 100 MB/sec, lasts 5000 yearsOrders of magnitude beyond any processs needs40 bits can address a TB

  • 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 spaceMaybe all processes for all time?

  • Implications of Single Shared Address SpaceIPC is trivialShared memory, RPCSeparation of concepts of address space and protection domainUniform address space

  • Address Space and Protection DomainA process has a protection domainThe data that cannot be touched by other processesAnd an address spaceThe addresses it can generate and accessIn standard systems, these concepts are merged

  • Separating the ConceptsThese concepts are potentially orthogonalJust because you can issue an address doesnt mean you can access it(Though clearly to access an address you must be able to issue it)Existing hardware can support this separation

  • Context-Independent AddressingAddresses mean the same thing in any execution contextSo, a given address always refers to the same piece of dataKey concept of uniform-address systemsAllows many OS optimizations/improvements

  • Uniform-Addressing Allows Easy SharingAny process can issue any addressSo any data can be sharedAll thats required is changing protection to permit desired sharingSuggests programming methods that make wider use of sharing

  • To Opal SystemNew OS using uniform-addressingDeveloped at University of WashingtonNot intended as slight alteration to existing UNIX systemMost of the rest of material specific to Opal

  • Protection Mechanisms for Uniform-AddressingProtection domains are assigned portions of the address spaceThey can allow other protection domains to access themRead-onlyTransferable access permissionsSystem-enforced page-level locking

  • Program Execution in Uniform-Access MemoryExecuting a program creates a new protection domainThe new domain is assigned an unused portion of the address spaceBut it may also get access to used portionsE.g., a segment containing the required executable image

  • Virtual SegmentsGlobal address space is divided into segmentsEach composed of variable number of contiguous virtual pagesDomains can only access segments they attach toAttempting to access unattached segment causes a segment fault

  • Persistent Memory in OpalPersistent segments exist even when attached to no current domainRecoverable segments are permanently storedAnd can thus survive crashesAll Opal segments can be persistent and recoverablePointers can thus live forever on disk

  • Code Modules in OpalExecutable code stored in modulesIndependent of protection domainsPure modules can be easily sharedBecause they are essentially staticCan get benefit of dynamic loading without run-time linking

  • Address Space ReclamationTrivial in non-uniform-address systemsTricky in uniform-address systemsProblem akin to reclaiming i_nodes in the presence of hard linksBut even if segments improperly reclaimed, only trusting domains can be hurt

  • Windows NT IPCInter-thread communications Within a single processLocal procedure callsBetween processes on same machineShared memory

  • Windows NT and ThreadsWindows NT support multiple threads of control in a single process address spaceThreads share address spaceSo communication among them is through memory

  • Windows NT and Client/Server ComputingWindows NT strongly supports the client/server model of computingVarious OS services are built as servers, rather than part of the kernelWindows NT needs facilities to support client/server operationsWhich guide users to building client/server solution

  • Client/Server Computing and RPCIn client/server computing, clients request services from serversService can be requested in many waysBut RPC is a typical wayWindows NT uses a specialized service for single machine RPC

  • Local Procedure Call (LPC)Similar in many ways to RPCBut optimized to only work on a single machinePrimarily used to communicate with protected subsystemsWindows NT also provides a true RPC facility for genuinely distributed computing

  • Basic Flow of Control in Windows NT LPCApplication calls routine in an application programming interfaceWhich is usually in a dynamically linked libraryWhich sends a message to the server through a messaging mechanism

  • Windows NT LPC Messaging MechanismsMessages between port objectsMessage pointers into shared memoryUsing dedicated shared memory segments

  • Port ObjectsWindows NT is generally object-orientedPort objects support communicationsTwo types:Connection portsCommunication ports

  • Connection PortsUsed to establish connections between clients and serversNamed, so they can be locatedOnly used to set up communication ports

  • Communication PortsUsed to actually pass dataCreated in pairs, between given client and given serverPrivate to those two processesDestroyed when communications end

  • Windows NT Port ExampleClient processServer processConnection port

  • Windows NT Port ExampleClient processServer processConnection port

  • Windows NT Port ExampleClient processServer processConnection port

  • Windows NT Port ExampleCommunication portsClient processServer processConnection port

  • Message Passing through Port Object Message QueuesOne of three methods in Windows NT to pass messages1. Client submits message to OS2. OS copies to receivers queue3. Receiver copies from queue to its own address space

  • Characteristics of Message Passing via QueuesTwo message copies requiredFixed-sized, fairly short message ~256 bytesPort objects stored in system memorySo always accessible to OSFixed number of entries in message queue

  • Message Passing Through Shared MemoryUsed for messages larger than 256 bytesClient must create section objectShared memory segmentOf arbitrary sizeMessage goes into the sectionPointer to message sent to receivers queue

  • Setting up Section ObjectsPre-arranged through OS callsUsing virtual memory to map segment into both sender and receivers address spaceIf replies are large, need another segment for the receiver to store responsesOS doesnt format section objects

  • Characteristics of Message Passing via Shared MemoryCapable of handling arbitrarily large transfersSender and receiver can share a single copy of datai.e., data copied only onceRequires pre-arrangement for section object

  • Server Handling of RequestsWindows NT servers expect requests from multiple clientsTypically, they have multiple threads to handle requestsMust be sufficiently general to handle many different ports and section objects

  • Message Passing Through Quick LPCThird way to pass messages in Windows NTUsed exclusively with Win32 subsystemLike shared memory, but with a key differenceDedicated resources

  • Use of Dedicated Resources in Quick LPCTo avoid overhead of copyingNotification mess

View more >