Transcript Monitors, Interprocess Communication, and RPC

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)
CS-502 Fall 2006
Inter-process
Communication
1
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
2
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
3
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
4
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
5
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
6
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
7
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
8
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 */
CS-502 Fall 2006
}
}
/* child, write data to pipe */
write(pipefd[1], data, sizeof(DATA));
close(pipefd[1]);
exit(0);
Inter-process
Communication
9
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
10
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
CS-502 Fall 2006
Inter-process
Communication
11
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
12
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
13
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
14
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
15
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)
CS-502 Fall 2006
Inter-process
Communication
16
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
17
Monitors
shared data
at most one
process in monitor
at a time
CS-502 Fall 2006
Inter-process
Communication
operations (procedures)
18
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
19
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
20
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
21
Monitors – Condition Variables
CS-502 Fall 2006
Inter-process
Communication
22
Monitors
monitor ProducerConsumer {
void producer() {
condition full, empty;
item i;
integer count = 0;
while (TRUE) {
/* produce item i */
/* function prototypes */
ProducerConsumer.insert(i);
void insert(item i);
item remove();
}
}
}
void consumer() {
void producer();
item i;
void consumer();
while (TRUE) {
i =
ProducerConsumer.remove();
/* consume item i */
}
}
CS-502 Fall 2006
Inter-process
Communication
23
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
24
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
25
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
26
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)
CS-502 Fall 2006
Inter-process
Communication
27
Remote Procedure Call
CS-502 Fall 2006
Inter-process
Communication
28
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
29
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
30
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 clientside stubs
• Operation:–
– Stubs manage all of the details of remote communication between client
and server
CS-502 Fall 2006
Inter-process
Communication
31
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
32
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
33
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
34
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
35
Questions?
Next Topic
CS-502 Fall 2006
Inter-process
Communication
36