Core InterProcess Communication Mechanisms Historically Important - PowerPoint PPT Presentation


PPT – Core InterProcess Communication Mechanisms Historically Important PowerPoint presentation | free to download - id: 155cf3-ZThhY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Core InterProcess Communication Mechanisms Historically Important


Common examples of IPC ... nonblocking send: sender resumes operation immediately after sending ... Continue: resume process. User specified actions. Default ... – PowerPoint PPT presentation

Number of Views:47
Avg rating:3.0/5.0
Slides: 24
Provided by: fredk5
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Core InterProcess Communication Mechanisms Historically Important

Core Inter-Process Communication
Mechanisms(Historically Important)
  • Fred Kuhns
  • (, http//
  • Department of Computer Science and Engineering
  • Washington University in St. Louis

Cooperating Processes
  • Independent process cannot affect or be affected
    by the execution of another process.
  • Cooperating process can affect or be affected by
    the execution of another process
  • Advantages of process cooperation
  • Information sharing
  • Computation speed-up
  • Modularity
  • Convenience
  • Dangers of process cooperation
  • Data corruption, deadlocks, increased complexity
  • Requires processes to synchronize their processing

Purposes for IPC
  • Data Transfer
  • Sharing Data
  • Event notification
  • Resource Sharing and Synchronization
  • Process Control

IPC Mechanisms
  • Mechanisms used for communication and
  • Message Passing
  • message passing interfaces, mailboxes and message
  • sockets, STREAMS, pipes
  • Shared Memory Non-message passing systems
  • Common examples of IPC
  • Synchronization using primitives such as
    semaphores to higher level mechanisms such as
    monitors. Implemented using either shared memoru
    or message passing.
  • Debugging
  • Event Notification - UNIX signals
  • We will defer a detailed discussion of
    synchronization mechanisms and concurrency until
    a later class
  • Here we want to focus on some common (and
    fundamental) IPC and event notification mechanisms

Message Passing
  • In a Message passing system there are no shared
    variables. IPC facility provides two operations
    for fixed or variable sized message
  • send(message)
  • receive(message)
  • If processes P and Q wish to communicate, they
    need to
  • establish a communication link
  • exchange messages via send and receive
  • Implementation of communication link
  • physical (e.g., shared memory, hardware bus)
  • logical (e.g., syntax and semantics, abstractions)

Implementation Questions
  • How are links established?
  • Can a link be associated with more than two
  • How are links made known to processes?
  • How many links can there be between every
    pair/group of communicating processes?
  • What is the capacity of a link?
  • Is the size of a message that the link can
    accommodate fixed or variable?
  • Is a link unidirectional or bi-directional?

Message Passing Systems
  • Exchange messages over a communication link
  • Methods for implementing the communication link
    and primitives (send/receive)
  • Direct or Indirect communications (Naming)
  • Symmetric or Asymmetric communications
  • Automatic or Explicit buffering
  • Send-by-copy or send-by-reference
  • fixed or variable sized messages

Direct Communication Internet and Sockets
  • Processes must name each other explicitly
  • Symmetric Addressing
  • send (P, message) send to process P
  • receive(Q, message) receive from Q
  • Asymmetric Addressing
  • send (P, message) send to process P
  • receive(id, message) rx from any system sets
    id sender
  • Primitives
  • send(A, message) send a message to mailbox A
  • receive(A, message) receive a message from
    mailbox A
  • Properties of communication link
  • Links established automatically between pairs
  • processes must know each others ID
  • Exactly one link per pair of communicating
  • Disadvantage a process must know the name or ID
    of the process(es) it wishes to communicate with

Indirect Communication - Pipes
  • Messages are sent to or received from mailboxes
    (also referred to as ports).
  • Each mailbox has a unique id.
  • Processes can communicate only if they share a
  • Properties of communication link
  • Link established only if processes share a common
  • A link may be associated with more than 2
  • Each pair of processes may share several
    communication links.
  • Ownership
  • process owns (i.e. mailbox is implemented in user
    space) only the owner may receive messages
    through this mailbox. Other processes may only
    send. When process terminates any owned
    mailboxes are destroyed.
  • system owns then mechanisms provided to create,
    delete, send and receive through mailboxes.
    Process that creates mailbox owns it (and so may
    receive through it) but may transfer ownership to
    another process.

Indirect Communication
  • Mailbox sharing
  • P1, P2, and P3 share mailbox A.
  • P1, sends P2 and P3 receive.
  • Who gets the message?
  • Solutions
  • Allow a link to be associated with at most two
  • Allow only one process at a time to execute a
    receive operation.
  • Allow the system to select arbitrarily the
    receiver. Sender is notified who the receiver

Synchronizing Message Flow
  • Message passing may be either blocking or
  • blocking send sender blocked until message
    received by mailbox or process
  • nonblocking send sender resumes operation
    immediately after sending
  • blocking receive receiver blocks until a message
    is available
  • nonblocking receive receiver returns immediately
    with either a valid or null message.

  • All messaging system require framework to
    temporarily buffer messages. These queues are
    implemented in one of three ways
  • Zero capacity No messages may be queued within
    the link, requires sender to block until receives
    retrieves message.
  • Bounded capacity Link has finite number of
    message buffers. If no buffers are available then
    sender must block until one is freed up.
  • Unbounded capacity Link has unlimited buffer
    space, consequently send never needs to block.

Lets Get Practical
Notes to help you with the first project
Conventional View
Protection domains - (virtual address space)
process 2
process n
process 1
How can processes communicate with each other
and the kernel?
Universal IPC Facilities
process 2
handle event
  • Universal Facilities in UNIX
  • Signals - asynchronous or synchronous event
  • Pipes - unidirectional, FIFO, unstructured data
  • Process tracing - used by debuggers to control
    control target process

Signals - History
  • Unreliable Signals - Orignal System V (SVR2 and
    earlier) implementation.
  • Handlers are not persistent
  • recurring instances of signal are not masked, can
    result in race conditions.
  • Reliable Signals - BSD and SVR3. Fixed problems
    but approaches differ.
  • POSIX 1003.1 (POSIX.1) defined standard set of

Signals Overview
  • Divided into asynchronous (CTL-C) and synchronous
    (illegal address)
  • Three phases to processing signals
  • generation event occurs requiring process
  • delivery process recognizes and takes
    appropriate action
  • pending between generation and delivery
  • SVR4 and 4.4BSD define 31 signals, original had
    15. Some commercial system support gt 32.
  • Signal to integer mappings differ between BSD and
    System V implementations

Signals - Virtual Machine Model
signal handler stack
Process X
(Signal handles)
instruction set
register handlers
dispatch to handler
(restartable system calls)
deliver signal
I/O facilities
  • Handling, default actions
  • Abort terminate process, generate core dump
  • Exit terminate without generating core dump
  • Ignore ignore signal
  • Stop suspend process
  • Continue resume process
  • User specified actions
  • Default action,
  • Ignore signal,
  • Catch signal - invoke user specified signal
  • User may
  • not ignore, catch or block SIGKILL and SIGSTOP
  • change action at any time
  • block signal signal remains pending until

  • Signal action may only be taken within context of
    receiving process
  • Process must be scheduled to run
  • Checks for pending signals when
  • before returning to user mode from a system call
    or interrupt
  • before blocking in an interruptible system event
  • immediately after waking from an interruptible
  • if pending signal and process has handler, then
    kernel arranges to first run handler on returning
    to user mode, then resume the interrupted

Signal Generation
  • Exceptions - kernel notifies process with signal
  • Other Process - using kill or sigsend.
  • Terminal interrupts - stty allows binding of
    signals to specific keys, sent to foreground
  • Job control - background processes attempt to
    read/write to terminal. Process terminate or
    suspends, kernels sends signal to parent
  • Quotas - exceeding limits
  • Notifications - event notification (device ready)
  • Alarms - process notified of alarm via signal

Reliable Signals - BSD
  • Persistent handlers
  • Masking signals
  • signals masked (blocked) temporarily
  • user can specify mask set for each signal
  • current signal is masked when handler invoked
  • Interruptible sleeps
  • Restartable system calls
  • Allocate separate stack for handling signals
  • why is this important?

Signals - A Few Details
  • Any process or interrupt can post a signal
  • set bit in pending signal bit mask
  • perform default action or setup for delivery
  • Signal typically delivered in context of
    receiving process.
  • exception is sending SIGSTOP, kernel may perform
    action directly
  • Pending signals are checked before returning to
    user mode and just before/after certain sleep
  • Produce core dump or invoke signal handler

UNIX Pipes
  • Unidirectional, FIFO, unstructured data stream
  • Fixed maximum size
  • Simple flow control
  • pipe() system call creates two file descriptors.
  • Implemented using filesystem, sockets or STREAMS
    (bidirectional pipe).
  • Named Pipes
  • Lives in the filesystem - that is, a file is
    created of type S_IFIFO (use mknod() or mkfifo())
  • may be accessed by unrelated processes
  • persistent
  • less secure than regular Pipes. Why?

Process Tracing
  • ptrace()
  • used by debuggers such as dbx and gdb.
  • Parent process controls execution of child
  • child must notify kernel that it will be traced
    by parent
  • Modern systems use the /proc file system.
  • Allows process to trace unrelated processes