1. Interprocess Communication (IPC)
CS-502 Operating Systems Fall 2006
(Slides include materials from Operating System Concepts, 7th ed., by Silbershatz, Galvin, & Gagne and from Modern Operating Systems, 2nd ed., by Tanenbaum)
Assumptions:
Graduate level
Operating Systems
Making Choices about operation systems
Why a micro-century? …just about enough time for one concept
CS-502 Fall 2006
Inter-process Communication

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
CS-502 Fall 2006
Inter-process Communication

3. Inter-process Communication
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
CS-502 Fall 2006
Inter-process Communication

4. Inter-process Communication
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)
CS-502 Fall 2006
Inter-process Communication

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
CS-502 Fall 2006
Inter-process Communication

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.
CS-502 Fall 2006
Inter-process Communication

7. Software Interrupts (continued)
SendInterrupt(pid, num)
Send signal type num to process pid,
kill() in Unix
(NT doesn’t 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
CS-502 Fall 2006
Inter-process Communication

8. Inter-process Communication
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)
CS-502 Fall 2006
Inter-process Communication

9. Inter-process Communication
IPC – Pipes
#include <iostream.h>
#include <unistd.h
#include <stdlib.h>
#define BUFFSIZE 1024
char data[ ] = “whatever”
int pipefd[2]; /* file descriptors for pipe ends */
/* NO ERROR CHECKING, ILLUSTRATION ONLY!!!!! */
main() {
char sbBuf[BUFFSIZE];
pipe(pipefd);
if (fork() > 0 ) { /* parent, read from pipe */
close(pipefd[1]); /* close write end */
read(pipefd[0], sbBuf, BUFFSIZE);
/* do something with the data */ }
else { close(pipefd[0]); /* close read end */
/* child, write data to pipe */
write(pipefd[1], data, sizeof(DATA));
close(pipefd[1]);
exit(0);
CS-502 Fall 2006
Inter-process Communication

10. Inter-process Communication
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!
CS-502 Fall 2006
Inter-process Communication

11. Inter-process Communication
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
Returns if there is a message
Blocks if not
Returns 1st message if there is one
Returns indication if no message
CS-502 Fall 2006
Inter-process Communication

12. Inter-process Communication
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)
CS-502 Fall 2006
Inter-process Communication

13. Inter-process Communication
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
CS-502 Fall 2006
Inter-process Communication

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)
CS-502 Fall 2006
Inter-process Communication

15. Inter-process Communication
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
CS-502 Fall 2006
Inter-process Communication

16. Inter-process Communication
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 , Oct (.pdf, correction)
CS-502 Fall 2006
Inter-process Communication

17. Inter-process Communication
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
CS-502 Fall 2006
Inter-process Communication

18. Monitors shared data at most one process in monitor at a time
operations (procedures)
CS-502 Fall 2006
Inter-process Communication

19. Inter-process Communication
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
wait’ing process relinquishes monitor temporarily
CS-502 Fall 2006
Inter-process Communication

20. Inter-process Communication
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.
CS-502 Fall 2006
Inter-process Communication

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)
CS-502 Fall 2006
Inter-process Communication

22. Monitors – Condition Variables
CS-502 Fall 2006
Inter-process Communication

23. Inter-process Communication
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() {
i = ProducerConsumer.remove();
/* consume item i */
CS-502 Fall 2006
Inter-process Communication

24. Inter-process Communication
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;
CS-502 Fall 2006
Inter-process Communication

25. Inter-process Communication
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
CS-502 Fall 2006
Inter-process Communication

26. Inter-process Communication
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;
CS-502 Fall 2006
Inter-process Communication

27. Inter-process Communication
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 , Feb (.pdf)
Redell, D. D. et al. “Pilot: An Operating System for a Personal Computer,” Communications of ACM, vol. 23, pp , Feb (.pdf)
CS-502 Fall 2006
Inter-process Communication

28. Inter-process Communication
Remote Procedure Call
CS-502 Fall 2006
Inter-process Communication

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
CS-502 Fall 2006
Inter-process Communication

30. Inter-process Communication
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?
CS-502 Fall 2006
Inter-process Communication

31. Inter-process Communication
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: Sun’s 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 service’s 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
CS-502 Fall 2006
Inter-process Communication

32. Inter-process Communication
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 server’s 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 it’s invoking the server
but it’s calling into the client-side stub
The server program thinks it’s called by the client
but it’s really called by the server-side stub
The stubs send messages to each other to make the RPC happen transparently (almost!)
CS-502 Fall 2006
Inter-process Communication

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
CS-502 Fall 2006
Inter-process Communication

34. Inter-process Communication
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
CS-502 Fall 2006
Inter-process Communication

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)
CS-502 Fall 2006
Inter-process Communication

36. Inter-process Communication
Questions?
Next Topic
CS-502 Fall 2006
Inter-process Communication