1 / 62

Advanced Operating Systems

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

gavril
Download Presentation

Advanced Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Advanced Operating Systems Lecture 5: Interprocess Communication University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Distributed Operating Systems

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. Ideal IPC Characteristics • Fast • Easy to use • Well defined synchronization model • Versatile • Easy to implement • Works remotely Distributed Operating Systems

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. Message-Based IPC Diagram OS Process B Process A Data sent from A to B B’s message queue Distributed Operating Systems

  15. 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

  16. Procedure IPC Diagram main () { . call(); . . . } . . . server(); . . . Data as parameters Data as return values Process B Process A Distributed Operating Systems

  17. 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

  18. 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

  19. 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

  20. 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

  21. UNIX IPC Mechanisms • Different versions of UNIX introduced different IPC mechanisms • Pipes • Message queues • Semaphores • Shared memory • Sockets • RPC Distributed Operating Systems

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. Problems with Shared Memory • Synchronization • Protection • Pointers Distributed Operating Systems

  31. 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

  32. 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

  33. 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

  34. A Troublesome Pointer a: __ b: __ z: __ y: 20 x: 10 w: 5 Process B Process A Distributed Operating Systems

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. Windows NT IPC • Inter-thread communications • Within a single process • Local procedure calls • Between processes on same machine • Shared memory Distributed Operating Systems

  41. 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

  42. 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

  43. 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

  44. Windows NT LPC Messaging Mechanisms • Messages between port objects • Message pointers into shared memory • Using dedicated shared memory segments Distributed Operating Systems

  45. 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

  46. Windows NT Port Example Connection port Server process Client process Distributed Operating Systems

  47. Windows NT Port Example Connection port Server process Client process Distributed Operating Systems

  48. Communication ports Windows NT Port Example Connection port Server process Client process Distributed Operating Systems

  49. Send request Windows NT Port Example Connection port Communication ports Server process Client process Distributed Operating Systems

  50. 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

More Related