Interprocess%20Communication%20(IPC)

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

2
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

3
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

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

5
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

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

7
Software Interrupts (continued)

• SendInterrupt(pid, num)
• Send signal type num to process pid,
• kill() in Unix
• (NT doesnt 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

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

9
IPC Pipes
include ltiostream.hgt include ltunistd.h include
ltstdlib.hgt define BUFFSIZE 1024 char data
whatever int pipefd2 / file descriptors for
pipe ends / / NO ERROR CHECKING, ILLUSTRATION
ONLY!!!!! / main() char sbBufBUFFSIZE
pipe(pipefd) if (fork() gt 0 ) / parent,
read from pipe / close(pipefd1) / close
write end / read(pipefd0, sbBuf, BUFFSIZE)
/ do something with the data / else
close(pipefd0) / close read end / /
child, write data to pipe / write(pipefd1,
data, sizeof(DATA)) close(pipefd1) exit(0
)
10
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!

11
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

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

13
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

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

15
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

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

17
Monitors

• High-level synchronization allowing safe sharing
  of an abstract data type among concurrent
  processes.
• monitor monitor-name
• shared variable declarations
• procedure body P1 ()
• . . .
• procedure body P2 ()
• . . .
• procedure body Pn ()
• . . .
• initialization code

18
Monitors
shared data
at most one process in monitor at a time
operations (procedures)
19
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 wait or signal others to continue
• condition variable can only be accessed from
  inside monitor
• waiting process relinquishes monitor temporarily

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

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

22
Monitors Condition Variables
23
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 /
24
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

25
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

26
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

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

28
Remote Procedure Call
29
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

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

31
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 Suns 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 services
  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

32
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 servers 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 its invoking the
  server
• but its calling into the client-side stub
• The server program thinks its called by the
  client
• but its really called by the server-side stub
• The stubs send messages to each other to make the
  RPC happen transparently (almost!)

33
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

34
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

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

36
Questions?

• Next Topic