InterProcess Communication - PowerPoint PPT Presentation

Loading...

PPT – InterProcess Communication PowerPoint presentation | free to download - id: 214ff7-NWUwO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

InterProcess Communication

Description:

signal remains pending until unblocked. Fred Kuhns (*) CS523 Operating Systems. 10 ... proxy. port. proxy. port. client. port. server. port. Host A. Host B ... – PowerPoint PPT presentation

Number of Views:133
Avg rating:3.0/5.0
Slides: 34
Provided by: fredk9
Learn more at: http://www.arl.wustl.edu
Category:

less

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

Title: InterProcess Communication


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

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

3
Conventional View
Protection domains - (for example, virtual
address space)
user
process 2
process n
process 1
kernel
How can processes communicate with each other and
the kernel?
4
Universal IPC Facilities
handler
user
process 2
dbx
kernel
stop
handle event
5
Universal Facilities
  • Signals - asynchronous or synchronous event
    notification.
  • Pipes - unidirectional, FIFO, unstructured data
    stream.
  • Process tracing - used by debuggers to control
    control target process

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

7
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

8
Handling Signals (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

9
User Specified Actions
  • User specified actions
  • Default action,
  • Ignore signal,
  • Catch signal - invoke user specified signal
    handler
  • User may not ignore, catch or block SIGKILL and
    SIGSTOP
  • User may change action at any time
  • User may block signal
  • signal remains pending until unblocked

10
Note
  • Signal action may only be taken within context of
    receiving process
  • Process must be scheduled to run
  • kernel calls issig() on behalf of process to
    check for pending signals. issig is called 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 processes has handler, then
    kernel arranges to first run handler on returning
    to user mode, then resume the interrupted
    instruction.

11
Signal Generation
  • Exceptions - kernel notifies process with signal
  • Other Process - signals sent to process or set of
    processes 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. Job control shells
    control foreground/background processes. 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

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

13
Signals - Virtual Machine Model
signal handler stack
Process X
(Signal handles)
dispatch to handler
instruction set
register handles
kernel
(restartable system calls)
deliver signal
I/O facilities
filesystem
scheduler
14
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

15
UNIX Pipes
  • Unidirectional, FIFO, unstructured data stream
  • Fixed maximum size
  • Simple flow control
  • pipe() system call creates two file descriptors.
  • Why two?
  • Implemented using filesystem, sockets or STREAMS
    (bidirectional pipe).

16
Named Pipes
  • Lives in the filesystem - 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?

17
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

18
System V IPC Mechanisms
  • Semaphores
  • Message queues
  • Shared memory

19
Common Elements
  • Common Attributes
  • key - integer identifying a resource instance
  • Creator - usr and group id of resource creator
  • Owner - usr and group id of owner
  • Permissions - FS style read/write/execute
  • shmget(key,), semget(key,), msgget(key,)
  • key can be generated from a filename and integer
    (ftok()) or IPC_PRIVATE.

20
Common Facilities
  • Resources are persistent, thus must be deleted
    when no longer needed - must be owner, creator or
    superuser.
  • shmctl(shmid,), semctl(semid,), msgctl(msgid,)
  • Fixed size resource table ipc_perm structure
    plus type specific data
  • resource id seq table_size index

21
System V Semaphores
Application
semop(semid, sops, nsops)
sem12, sem31, block until sem4 0
Semaphore set (semid, kernel)
22
System V Message Queues
Send new message
msgrcv(msgqid, msgp, maxcnt, msgtype, flag)
type
data
data
data
type
type
FIFO
23
System V Shared Memory
0x00000000
user
Process 3
process 1
process 2
kernel
24
MACH IPC
  • Message passing fundamental mechanism,
  • user-user and user-kernel
  • avoid unnecessary data copies
  • provide copy-on-write mechanisms
  • kernel must provide secure communications
  • transparently extensible to distributed
    environment
  • Tightly coupled with virtual memory

25
The Basics
  • Message - collection of typed data
  • simple - contains ordinary data
  • complex - contains ordinary data, out-of-line
    data (uses copy-on-write), send or receive rights
    to various ports. Kernel transforms complex data
    so meaningful for receive.
  • Port - protected queue of messages
  • message can only be sent to a port
  • tasks own send and receive rights
  • several tasks may own send rights to a port, but
    only one task (the owner) has receive rights
  • Ports also represent kernel objects (threads,
    tasks etc). kernel hold receive rights.

26
MACH Ports
  • each thread and task have default ports,
  • send rights to task_self port, kernel receive
  • read rights to task_notify
  • send rights to a bootstrap port, access to
    nameserver
  • send rights to thread_self
  • receive rights to reply port, receive replies
    from system calls and rpc to other tasks
  • read rights to exception port
  • task owns rights to all port, so all threads can
    access any port

27
Message data structures
  • Ordinary data - physically copied by kernel
  • Out-of-line memory - copy-on-write
  • Send or receive ports
  • name - type of data

28
Interface
  • One-way send
  • Blocked read
  • wait for unsolicited msgs
  • Two-way asynchronous
  • send msg, receive reply asynchronously.
  • Blocking two-way
  • send msg and wait for reply.

29
Example
Client
30
MACH Message Passing
Sending Task
Receiving Task
In-line (data)
Copy of data
Copy of data
copy
copy
copy maps
Out-of-line (data)
Holding map
Address maps
copy maps
Port right (local name)
Port right (local name)
Pointer to port obj
translate
translate
Received message
Outgoing message
Internal message
31
IPC In Action
whereis server X
Use port x
register server X
request
reply
kernel
32
Distributed messaging in MACH
Host B
Host A
netmsgserver
netmsgserver
port
port
server
client
33
MACH IPC - Notes
  • Handoff scheduling
  • support for a fast path when receiver is
    scheduled immediately.
  • Notification
  • asynchronous message from kernel to task.
  • Port sets
  • group of ports with one receiver, and one receive
    queue (i.e. one receive right)
About PowerShow.com