Interprocess Communication (IPC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Monitors – Condition Variables Inter-process Communication

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

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

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

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

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

Remote Procedure Call Inter-process Communication

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

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

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

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

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

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

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

Questions? Next Topic Inter-process Communication

Interprocess Communication (IPC)