1 / 36

Interprocess Communication (IPC)

Interprocess Communication (IPC). CS-502 Operating Systems Fall 2006 (Slides include materials from Operating System Concepts , 7 th ed., by Silbershatz, Galvin, & Gagne and from Modern Operating Systems , 2 nd ed., by Tanenbaum). Interprocess Communication.

marny-mccoy
Download Presentation

Interprocess Communication (IPC)

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. Interprocess Communication (IPC) CS-502 Operating SystemsFall 2006 (Slides include materials from Operating System Concepts, 7th ed., by Silbershatz, Galvin, & Gagne and from Modern Operating Systems, 2nd ed., by Tanenbaum) Inter-process Communication

  2. Interprocess Communication • Wide Variety of interprocess communication (IPC) mechanisms – e.g., • Pipes & streams • Sockets & Messages • Remote Procedure Call • Shared memory techniques • OS dependent • Depends on whether the communicating processes share all, part, or none of an address space Inter-process Communication

  3. Common IPC mechanisms • Shared memory – read/write to shared region • E.g., shmget(), shmctl() in Unix • Memory mapped files in WinNT/2000 • Need critical section management • Semaphores – post_s() notifies waiting process • Shared memory or not, but semaphores need to be shared • Software interrupts - process notified asynchronously • signal () • Pipes - unidirectional stream communication • Message passing - processes send and receive messages • Across address spaces • Remote procedure call – processes call functions in other address spaces • Same or different machines Inter-process Communication

  4. Shared Memory • Straightforward if processes already share entire address space • E.g., threads of one processes • E.g., all processes of some operating systems • eCos, Pilot • Critical section management • Semaphores (or equivalent) • Monitors (see later) Inter-process Communication

  5. Shared Memory (continued) • More difficult if processes inherently have independent address spaces • E.g., Unix, Linux, Windows • Special mechanisms to share a portion of virtual memory • E.g., shmget(), shmctl() in Unix • Memory mapped files in Windows XP/2000, Apollo DOMAIN, etc. • Very, very hard to program! • Need critical section management among processes • Pointers are an issue Inter-process Communication

  6. IPC – Software Interrupts • Similar to hardware interrupt. • Processes interrupt each other • Non-process activities interrupt processes • Asynchronous! Stops execution then restarts • Keyboard driven – e.g. cntl-C • An alarm scheduled by the process expires • Unix: SIGALRM from alarm() or settimer() • resource limit exceeded (disk quota, CPU time...) • programming errors: invalid data, divide by zero, etc. Inter-process Communication

  7. Software Interrupts (continued) • SendInterrupt(pid, num) • Send signal type num to process pid, • kill() in Unix • (NT doesn’t allow signals to processes) • HandleInterrupt(num, handler) • type num, use function handler • signal() in Unix • Use exception handler in WinNT/2000 • Typical handlers: • ignore • terminate (maybe w/core dump) • user-defined Inter-process Communication

  8. IPC – Pipes • A pipe is a unidirectional stream connection between 2 processes • i.e., an example of a Producer-Consumer • Unix/Linux • 2 file descriptors • Byte stream • Win/NT • 1 handle • Byte stream and structured (messages) Inter-process Communication

  9. IPC – Pipes #include <iostream.h> #include <unistd.h #include <stdlib.h> #define BUFFSIZE 1024 char data[ ] = “whatever” int pipefd[2]; /* file descriptors for pipe ends */ /* NO ERROR CHECKING, ILLUSTRATION ONLY!!!!! */ main() { char sbBuf[BUFFSIZE]; pipe(pipefd); if (fork() > 0 ) { /* parent, read from pipe */ close(pipefd[1]); /* close write end */ read(pipefd[0], sbBuf, BUFFSIZE); /* do something with the data */ } else { close(pipefd[0]); /* close read end */ /* child, write data to pipe */ write(pipefd[1], data, sizeof(DATA)); close(pipefd[1]); exit(0); } } Inter-process Communication

  10. IPC – Message Passing • Communicate information from one process to another via:– send(dest, &message) receive(source, &message) • Receiver can specify ANY • Receiver can choose to block or not • Applicable to single- and multi-processor and distributed systems • Pre-dates semaphores • Does not require shared address spaces! Inter-process Communication

  11. IPC – Message Passing • 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 or acknowledgement • Blocks if buffer is full (perhaps) • receive () operation • Synchronous • Returns if there is a message • Blocks if not • Asynchronous • Returns 1st message if there is one • Returns indication if no message Inter-process Communication

  12. IPC – Message Passing • 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 • Within one machine and among machines • MACH (CMU) • GEC 4080 (British telephone exchanges) Inter-process Communication

  13. Acknowledgements • A message back to sender indicating that original message was received correctly • May be sent piggy-back on another message • Implicit or explicit • May be synchronous or asynchronous • May be positive or negative Inter-process Communication

  14. Message Passing issues • Scrambled messages (checksum) • Lost messages (acknowledgements) • Lost acknowledgements (sequence no.) • Destination unreachable (down, terminates) • Mailbox full • Naming • Authentication • Performance (copying, message building) Inter-process Communication

  15. Beyond Semaphores • Semaphores can help solve many traditional synchronization problems, BUT: • Have no direct relationship to the data being controlled • Difficult to use correctly; easily misused • Global variables • Proper usage requires superhuman attention to detail • Another approach – use programming language support Inter-process Communication

  16. Monitors • Programming language construct that supports controlled access to shared data • Compiler adds synchronization automatically • Enforced at runtime • Encapsulates • Shared data structures • Procedures/functions that operate on the data • Synchronization between processes calling those procedures • Only one process active inside a monitor at any instant • All procedures are part of critical section Hoare, C.A.R., “Monitors: An Operating System Structuring Concept,” Communications of ACM, vol. 17, pp. 549-557, Oct. 1974 (.pdf, correction) Inter-process Communication

  17. Monitors • High-level synchronization allowing safe sharing of an abstract data type among concurrent processes. monitor monitor-name { shared variable declarations procedure bodyP1(…) { . . . } procedurebodyP2 (…) { . . . } procedure bodyPn(…) { . . . } { initialization code } } Inter-process Communication

  18. Monitors shared data at most one process in monitor at a time operations (procedures) Inter-process Communication

  19. Monitors • Mutual exclusion • only one process can be executing inside at any time • if a second process tries to enter a monitor procedure, it blocks until the first has relinquished the monitor • Once inside a monitor, process may discover it is not able to continue • condition variables provided within monitor • processes can waitor signal others to continue • condition variable can only be accessed from inside monitor • wait’ing process relinquishes monitor temporarily Inter-process Communication

  20. Monitors • To allow a process to wait within the monitor, a condition variable must be declared, as condition x; • Condition variable can only be used with the operations wait and signal. • The operation wait(x);means that the process invoking this operation is suspended until another process invokes signal(x); • The signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect. Inter-process Communication

  21. wait and signal(continued) • When process invokes wait, it relinquishes the monitor lock to allow other processes in. • When process invokes signal, the resumed process must reacquire monitor lock before it can proceed (inside the monitor) Inter-process Communication

  22. Monitors – Condition Variables Inter-process Communication

  23. Monitors • monitor ProducerConsumer { • condition full, empty; • integer count = 0; • /* function prototypes */ • void insert(item i); • item remove(); • } • void producer(); • void consumer(); void producer() { item i; while (TRUE) { /* produce item i */ ProducerConsumer.insert(i); } } void consumer() { item i; while (TRUE) { i = ProducerConsumer.remove(); /* consume item i */ } } Inter-process Communication

  24. Monitors void insert (item i) { if (count == N) wait(full); /* add item i */ count = count + 1; if (count == 1) then signal(empty); } item remove () { if (count == 0) wait(empty); /* remove item into i */ count = count - 1; if (count == N-1) signal(full); return i; } Inter-process Communication

  25. Monitors – variations • Hoare monitors: signal(c) means • run waiting process immediately (and acquires monitor lock) • signaler blocks immediately (and releases lock) • condition guaranteed to hold when waiter runs • Mesa/Pilot monitors: signal(c) means • Waiting process is made ready, but signaler continues • waiter competes for monitor lock when signaler leaves monitor (or waits) • condition is not necessarily true when waiter runs again • being woken up is only a hint that something has changed • must recheck conditional case Inter-process Communication

  26. Monitors (Mesa) void insert (item i) { while (count == N) wait(full); /* add item i */ count = count + 1; if (count == 1) then signal(empty); } item remove () { while (count == 0) wait(empty); /* remove item into i */ count = count - 1; if (count == N-1) signal(full); return i; } Inter-process Communication

  27. Synchronization • Semaphores • Easy to add, regardless of programming language • Much harder to use correctly • Monitors • Easier to use and to get it right • Must have language support • Available in Java • See • Lampson, B.W., and Redell, D. D., “Experience with Processes and Monitors in Mesa,” Communications of ACM, vol. 23, pp. 105-117, Feb. 1980. (.pdf) • Redell, D. D. et al. “Pilot: An Operating System for a Personal Computer,” Communications of ACM, vol. 23, pp. 81-91, Feb. 1980. (.pdf) Inter-process Communication

  28. Remote Procedure Call Inter-process Communication

  29. Remote Procedure Call (RPC) • The most common means for communicating among processes of different address spaces • Used both by operating systems and by applications • NFS is implemented as a set of RPCs • DCOM, CORBA, Java RMI, etc., are just RPC systems • Fundamental idea: – • Server processes export an interface of procedures/functions that can be called by client programs • similar to library API, class definitions, etc. • Clients make local procedure/function calls • As if directly linked with the server process • Under the covers, procedure/function call is converted into a message exchange with remote server process Inter-process Communication

  30. RPC – Issues • How to make the “remote” part of RPC invisible to the programmer? • What are semantics of parameter passing? • E.g., pass by reference? • How to bind (locate & connect) to servers? • How to handle heterogeneity? • OS, language, architecture, … • How to make it go fast? Inter-process Communication

  31. RPC Model • A server defines the service interface using an interface definition language (IDL) • the IDL specifies the names, parameters, and types for all client-callable server procedures • example: Sun’s XDR (external data representation) • A stub compiler reads the IDL declarations and produces two stub functions for each server function • Server-side and client-side • Linking:– • Server programmer implements the service’s functions and links with the server-side stubs • Client programmer implements the client program and links it with client-side stubs • Operation:– • Stubs manage all of the details of remote communication between client and server Inter-process Communication

  32. RPC Stubs • A client-side stub is a function that looks to the client as if it were a callable server function • I.e., same API as the server’s implementation of the function • A server-side stub looks like a caller to the server • I.e., like a hunk of code invoking the server function • The client program thinks it’s invoking the server • but it’s calling into the client-side stub • The server program thinks it’s called by the client • but it’s really called by the server-side stub • The stubs send messages to each other to make the RPC happen transparently (almost!) Inter-process Communication

  33. Marshalling Arguments • Marshalling is the packing of function parameters into a message packet • the RPC stubs call type-specific functions to marshal or unmarshal the parameters of an RPC • Client stub marshals the arguments into a message • Server stub unmarshals the arguments and uses them to invoke the service function • on return: • the server stub marshals return values • the client stub unmarshals return values, and returns to the client program Inter-process Communication

  34. RPC Binding • Binding is the process of connecting the client to the server • the server, when it starts up, exports its interface • identifies itself to a network name server • tells RPC runtime that it is alive and ready to accept calls • the client, before issuing any calls, imports the server • RPC runtime uses the name server to find the location of the server and establish a connection • The import and export operations are explicit in the server and client programs Inter-process Communication

  35. Remote Procedure Call is used … • Between processes on different machines • E.g., client-server model • Between processes on the same machine • More structured than simple message passing • Between subsystems of an operating system • Windows XP (called Local Procedure Call) Inter-process Communication

  36. Questions? Next Topic Inter-process Communication

More Related