1. Inter-process Communication CS-502 Fall 20061 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)

2. Inter-process Communication CS-502 Fall 20062 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

3. Inter-process Communication CS-502 Fall 20063 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

4. Inter-process Communication CS-502 Fall 20064 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)

5. Inter-process Communication CS-502 Fall 20065 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

6. Inter-process Communication CS-502 Fall 20066 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.

7. Inter-process Communication CS-502 Fall 20067 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

8. Inter-process Communication CS-502 Fall 20068 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)

9. Inter-process Communication CS-502 Fall 20069 IPC – Pipes #include #include <unistd.h #include #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); }

10. Inter-process Communication CS-502 Fall 200610 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!

11. Inter-process Communication CS-502 Fall 200611 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 1 st message if there is one –Returns indication if no message

12. Inter-process Communication CS-502 Fall 200612 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)

13. Inter-process Communication CS-502 Fall 200613 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

14. Inter-process Communication CS-502 Fall 200614 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)

15. Inter-process Communication CS-502 Fall 200615 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

16. Inter-process Communication CS-502 Fall 200616 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).pdfcorrection

17. Inter-process Communication CS-502 Fall 200617 Monitors High-level synchronization allowing safe sharing of an abstract data type among concurrent processes. monitor monitor-name { shared variable declarations procedure body P1 (…) {... } procedure body P2 (…) {... } procedure body Pn (…) {... } { initialization code }

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

19. Inter-process Communication CS-502 Fall 200619 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 wait or signal others to continue condition variable can only be accessed from inside monitor wait ’ing process relinquishes monitor temporarily

20. Inter-process Communication CS-502 Fall 200620 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.

21. Inter-process Communication CS-502 Fall 200621 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)

22. Inter-process Communication CS-502 Fall 200622 Monitors – Condition Variables

23. Inter-process Communication CS-502 Fall 200623 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 */ }

24. Inter-process Communication CS-502 Fall 200624 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; }

25. Inter-process Communication CS-502 Fall 200625 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

26. Inter-process Communication CS-502 Fall 200626 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; }

27. Inter-process Communication CS-502 Fall 200627 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).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).pdf

28. Inter-process Communication CS-502 Fall 200628 Remote Procedure Call

29. Inter-process Communication CS-502 Fall 200629 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

30. Inter-process Communication CS-502 Fall 200630 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?

31. Inter-process Communication CS-502 Fall 200631 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

32. Inter-process Communication CS-502 Fall 200632 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!)

33. Inter-process Communication CS-502 Fall 200633 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

34. Inter-process Communication CS-502 Fall 200634 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

35. Inter-process Communication CS-502 Fall 200635 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)

36. Inter-process Communication CS-502 Fall 200636 Questions? Next Topic