Inter-process Communication CS-502 Fall 20061 Interprocess Communication (IPC) CS-502 Operating Systems Fall 2006 (Slides include materials from Operating

Inter-process Communication

CS-502 Fall 2006 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)


CS-502 Fall 2006 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


CS-502 Fall 2006 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


CS-502 Fall 2006 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)


CS-502 Fall 2006 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


CS-502 Fall 2006 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.


CS-502 Fall 2006 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


CS-502 Fall 2006 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)


CS-502 Fall 2006 9

IPC – Pipes#include <iostream.h>#include <unistd.h#include <stdlib.h>#define BUFFSIZE 1024char 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);

}}


CS-502 Fall 2006 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!


CS-502 Fall 2006 11


– 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


CS-502 Fall 2006 12


• 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 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


CS-502 Fall 2006 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)


CS-502 Fall 2006 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


CS-502 Fall 2006 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)


CS-502 Fall 2006 17

Monitors• High-level synchronization allowing safe sharing of an

abstract data type among concurrent processes.monitor monitor-name{

shared variable declarationsprocedure body P1 (…) {

. . .}procedure body P2 (…) {

. . .} procedure body Pn (…) {

. . .} {

initialization code}

}


CS-502 Fall 2006 18

Monitors

shared data

operations (procedures)at most one process in monitor

at a time


CS-502 Fall 2006 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 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 20

Monitors• To allow a process to wait within the monitor, a

condition variable must be declared, ascondition 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 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)


CS-502 Fall 2006 22

Monitors – Condition Variables


CS-502 Fall 2006 23

Monitorsmonitor 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 */

}

}


CS-502 Fall 2006 24

Monitorsvoid 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 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


CS-502 Fall 2006 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;

}


CS-502 Fall 2006 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)


CS-502 Fall 2006 28

Remote Procedure Call


CS-502 Fall 2006 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


CS-502 Fall 2006 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?


CS-502 Fall 2006 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


CS-502 Fall 2006 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!)


CS-502 Fall 2006 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


CS-502 Fall 2006 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


CS-502 Fall 2006 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)


CS-502 Fall 2006 36

Questions?

Next Topic

Documents

Inter-process Communication CS-502 Fall 20061 Interprocess Communication (IPC) CS-502 Operating Systems Fall 2006 (Slides include materials from Operating