Core InterProcess Communication Mechanisms Historically Important - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Core InterProcess Communication Mechanisms Historically Important

Description:

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: http://www.arl.wustl.edu
Category:

less

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

Title: Core InterProcess Communication Mechanisms Historically Important


1
Core Inter-Process Communication
Mechanisms(Historically Important)
  • Fred Kuhns
  • (fredk_at_arl.wustl.edu, http//www.arl.wustl.edu/fr
    edk)
  • Department of Computer Science and Engineering
  • Washington University in St. Louis

2
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

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

4
IPC Mechanisms
  • Mechanisms used for communication and
    synchronization
  • Message Passing
  • message passing interfaces, mailboxes and message
    queues
  • 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

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

6
Implementation Questions
  • How are links established?
  • Can a link be associated with more than two
    processes?
  • 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?

7
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

8
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
    processes
  • Disadvantage a process must know the name or ID
    of the process(es) it wishes to communicate with

9
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
    mailbox.
  • Properties of communication link
  • Link established only if processes share a common
    mailbox
  • A link may be associated with more than 2
    processes.
  • 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.

10
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
    processes.
  • 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
    was

11
Synchronizing Message Flow
  • Message passing may be either blocking or
    non-blocking.
  • 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.

12
Buffering
  • 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.

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

16
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
    functions.

17
Signals Overview
  • Divided into asynchronous (CTL-C) and synchronous
    (illegal address)
  • Three phases to processing signals
  • generation event occurs requiring process
    notification
  • 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

18
Signals - Virtual Machine Model
signal handler stack
Process X
(Signal handles)
instruction set
register handlers
dispatch to handler
kernel
(restartable system calls)
deliver signal
I/O facilities
filesystem
scheduler
19
Actions
  • 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
    handler
  • User may
  • not ignore, catch or block SIGKILL and SIGSTOP
  • change action at any time
  • block signal signal remains pending until
    unblocked

20
Notes
  • 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
    event
  • if pending signal and process has handler, then
    kernel arranges to first run handler on returning
    to user mode, then resume the interrupted
    instruction.

21
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
    process
  • 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
    reception

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

23
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
    calls.
  • Produce core dump or invoke signal handler

24
UNIX Pipes
  • Unidirectional, FIFO, unstructured data stream
  • Fixed maximum size
  • Simple flow control
  • pipe() system call creates two file descriptors.
    Why?
  • 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?

25
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
About PowerShow.com