Interprocess communication ipc
1 / 36

Interprocess Communication (IPC) - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Interprocess Communication (IPC)' - marny-mccoy

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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
    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
    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
    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
    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
    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
    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 pipes1
    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 */


    main() {

    char sbBuf[BUFFSIZE];


    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));





    Inter-process Communication

    Ipc message passing
    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 passing1
    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 passing2
    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


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


    • 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


    • 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


    shared data

    at most one process in monitor at a time

    operations (procedures)

    Inter-process Communication


    • 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


    • 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


      • 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
    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
    Monitors – Condition Variables

    Inter-process Communication


    • 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


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


    • 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

    Remote Procedure Call

    Inter-process Communication

    Remote procedure call rpc
    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
    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
    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
    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 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
    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
    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



    Next Topic

    Inter-process Communication