InterProcess Communications IPC

1
Inter-Process Communications (IPC)

• Fred Kuhns
• CS422S

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

3
Producer-Consumer Problem

• Paradigm for cooperating processes, producer
  process produces information that is consumed by
  a consumer process.
• unbounded-buffer places no practical limit on the
  size of the buffer.
• bounded-buffer assumes that there is a fixed
  buffer size.

4
Bounded-Buffer Shared-Memory

• Shared data
• define BUFFER_SIZE 10
• Typedef struct
• . . .
• item
• item bufferBUFFER_SIZE
• int in 0
• int out 0
• Solution is correct, but can only use
  BUFFER_SIZE-1 elements

5
Bounded-Buffer Producer Process

• item nextProduced
• while (1)
• while (((in 1) BUFFER_SIZE) out)
• / do nothing /
• bufferin nextProduced
• in (in 1) BUFFER_SIZE

6
Bounded-Buffer Consumer Process

• item nextConsumed
• while (1)
• while (in out)
• / do nothing /
• nextConsumed bufferout
• out (out 1) BUFFER_SIZE

7
Purposes for IPC

• Data Transfer
• Sharing Data
• Event notification
• Resource Sharing and Synchronization
• Process Control

8
IPC Mechanisms

• Mechanisms used for communication and
  synchronization
• Message Passing ltFocus of Lecturegt
• message passing interfaces, mailboxes and message
  queues
• sockets, STREAMS, pipes
• Shared Memory (Non-message passing systems)
• Synchronization
• Debugging
• Event Notification - signals

9
Message Passing

• In a Message system there are no shared
  variables. IPC facility provides two operations
• send(message) size fixed or variable
• receive(message)
• If 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., logical properties)

10
Implementation Questions

• How are links established?
• Can a link be associated with more than two
  processes?
• How many links can there be between every pair 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?

11
Direct Communication

• 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
• Properties of communication link
• Links are established automatically
• A link is associated with exactly one pair of
  communicating processes.
• exactly one link between each pair.
• usually bi-directional.

12
Indirect Communication

• Messages are directed and 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 many processes.
• Each pair of processes may share several
  communication links.
• Link may be unidirectional or bi-directional.

13
Indirect Communication

• Operations
• create a new mailbox
• send and receive messages through mailbox
• destroy a mailbox
• Primitives
• send(A, message) send a message to mailbox A
• receive(A, message) receive a message from
  mailbox A

14
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

15
Synchronization

• Message passing may be either blocking or
  non-blocking.
• Blocking is considered synchronous
• Non-blocking is considered asynchronous
• send and receive primitives may be either
  blocking or non-blocking.

16
Buffering

• Queue of messages attached to the link
  implemented in one of three ways.
• 1. Zero capacity 0 messagesSender must wait
  for receiver (rendezvous).
• 2. Bounded capacity finite length of n
  messagesSender must wait if link full.
• 3. Unbounded capacity infinite length Sender
  never waits.

17
Client-Server Communication

• Sockets
• Remote Procedure Calls
• Remote Method Invocation (Java)

18
Sockets

• A socket is defined as an endpoint for
  communication.
• Socket protocol specific address
• Internet domain (INET) - concatenation of an IP
  address and port
• UNIX domain - pathnames within the normal
  filesystem.
• The socket 161.25.19.81625 refers to port 1625
  on host 161.25.19.8
• Communication consists between a pair of sockets.

19
INET Socket Communication
20
Remote Procedure Calls (RPC)

• Remote procedure call abstracts procedure calls
  between processes on networked systems.
• Stubs client-side proxy for the actual
  procedure on the server.
• The client-side stub locates the server and
  marshalls the parameters.
• The server-side stub receives this message,
  unpacks the marshalled parameters, and performs
  the procedure on the server.

21
Execution of RPC
22
Remote Method Invocation (RMI)

• Remote Method Invocation is a Java mechanism
  similar to RPCs.
• RMI allows a Java program on one machine to
  invoke a method on a remote object.

23
Marshalling Parameters
24
Error Recovery

• Process terminates
• Lost messages
• Scrambled Messages

25
UNIX Examples

• Basic UNIX InterProcess Communication Mechanisms.
• Universal IPC mechanisms
• S5R4 mechanisms
• Mach
• Synchronization primitives will be covered in
  subsequent lectures

26
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?
27
Universal IPC Facilities
handler
user
process 2
dbx
kernel
stop
handle event
Signals, Pipes and Process Tracing
28
Universal Facilities

• Signals - asynchronous or synchronous event
  notification.
• Pipes - unidirectional, FIFO, unstructured data
  stream.
• Process tracing - used by debuggers to control
  control target process

29
Signals -Terminology

• Post - The system delivers a signal to a process.
• Action - defines how a signaled is handled when
  delivered.
• Signal handler - User specified function to be
  invoked by the system when a specific signal
  occurs.
• Catch - a signal handler catches a signal.
• Masked - if a posted signal is masked then action
  is deferred until unmasked.

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

31
Signals Overview

• Divided into asynchronous and synchronous
• Two phases signal generation and delivery.
• SVR4 and 4.4BSD define 31 signals, original had
  15.
• Signal to integer mappings differ between BSD and
  System V implementations

32
Actions

• Default actions
• terminate w/core dump, terminate no core dump,
  ignore signal, stop process, resume execution of
  process
• User specified action
• Take default action, ignore signal, or catch
  signal with handler

33
Reliable Signals - BSD

• Persistent handlers
• Masking signals
• 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?

34
Signals - Virtual Machine Model
signal handler stack
Process X
(Signal handles)
instruction set
register handles
dispatch to handler
kernel
(restartable system calls)
deliver signal
I/O facilities
filesystem
scheduler
35
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 (unless it is sleeping).
• Pending signals are checked before returning to
  user mode and just before/after certain sleep
  calls.
• Produce core dump or invoke signal handler

36
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).

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

38
Process Tracing

• ptrace()
• used by debuggers such as dbx and gdb.
• Process must notify kernel that parent will trace
  it. How could we do this for an arbitrary
  program?
• SVR4 and Solaris provides /proc

39
System V IPC Mechanisms

• Semaphores
• Message queues
• Shared memory

40
Common Elements

• Common Attributes
• key - integer which identifies a resource
  instance
• Creator - usr and grp id of resource creator
• Owner - usr and grp 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.

41
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

42
SV Semaphores
Application
semop(semid, sops, nsops)
sem12, sem31, block until sem4 0
Semaphore set (semid, kernel)
43
SV Message Queues
New messages
msgid_ds
msgrcv(msgqid, msgp, maxcnt, msgtype, flag)
msgcnt, bytes maxbytes
type
data
data
data
type
type
FIFO
44
SV Shared Memory
0x00000000
user
Process 3
process 1
process 2
kernel
45
MACH IPC

• Message passing fundamental mechanism
• most system calls and inter-task communication
• Task is created with two mailboxes
• 1) Kernel mailbox
• 2) Notify mailbox
• avoid unnecessary data copies
• kernel must provide secure communication
• transparently extensible to distributed
  environments.
• Tightly coupled with virtual memory

46
The Basics

• Message - collection of typed data
• Port - protected queue of msgs
• Ports also represent kernel objects
• port has associated send and receive rights
• only one task (owner) has receive rights for a
  port
• multiple tasks may have send rights

47
Message data structures

• Ordinary data - physically copied by kernel
• Out-of-line memory - copy-on-write
• Send or receive ports

size flags
type size local_port destination_port message_id
data
name number
48
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.

49
A View
Client
50
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
51
IPC In Action
whereis server X
Use port x
register server X
request
reply
kernel
52
Distributed messaging in MACH
Host B
Host A
netmsgserver
netmsgserver
port
port
server
client
53
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)