Interprocess Communication IPC CS502 Operating Systems Fall 2006

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

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

Common IPC mechanisms • Shared memory – read/write to shared region – E. g. , shmget(), shmctl() in Unix – Memory mapped files in Win. NT/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 CS-502 Fall 2006 Inter-process Communication 3

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

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

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

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

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

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 sb. Buf[BUFFSIZE]; pipe(pipefd); if (fork() > 0 ) { /* parent, read from pipe */ close(pipefd[1]); /* close write end */ read(pipefd[0], sb. Buf, 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); } CS-502 Fall 2006 } Inter-process Communication 9

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

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 CS-502 Fall 2006 Inter-process Communication 11

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

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

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

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

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

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

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

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 CS-502 Fall 2006 Inter-process Communication 19

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

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

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

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

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

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

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

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

Remote Procedure Call CS-502 Fall 2006 Inter-process Communication 28

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

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

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 clientside stubs • Operation: – – Stubs manage all of the details of remote communication between client and server CS-502 Fall 2006 Inter-process Communication 31

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

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

RPC Binding • Binding is the process of connecting the client to the server – the server, when it starts up, exports 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 CS-502 Fall 2006 Inter-process Communication 34

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

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