Interprocess communication ipc
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Interprocess Communication (IPC) PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Interprocess Communication (IPC)

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

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

    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


    Acknowledgements

    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

    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


    Monitors

    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


    Monitors1

    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


    Monitors2

    Monitors

    shared data

    at most one process in monitor at a time

    operations (procedures)

    Inter-process Communication


    Monitors3

    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


    Monitors4

    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

    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


    Monitors5

    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


    Monitors6

    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

    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


    Synchronization

    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

    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


    Questions

    Questions?

    Next Topic

    Inter-process Communication


  • Login