IPC, Nachos
Tom Kelliher, CS42
Sept. 20, 1996
Basics: send(), receive() primitives.
Design Issues:
- Link establishment mechanisms:
- Direct or indirect naming.
- Circuit or no circuit.
- More than two processes per link (multicasting).
- Link buffering:
- Zero capacity.
- Bounded capacity.
- Infinite capacity.
- Variable- or fixed-size messages.
- Unidirectional or bidirectional links (symmetry).
- Resolving lost messages.
- Resolving out-of-order messages.
- Resolving duplicated messages.
Resources owned by kernel.
Messages kept in a queue.
Assume:
- Only allocating process may execute receive.
- Any process (including ``owner'') may send.
- Variable-sized messages.
- Infinite capacity.
Primitives:
- int AllocateMB(void)
- int Send(int mb, char* message)
- int Receive(int mb, char* message)
- int FreeMB(int mb)
Consider:
Process1()
{
...
S1;
...
}
Process2()
{
...
S2;
...
}
How can we guarantee that S1 executes before S2?
The situation:
Tape allocator process:
initialize();
while (1)
{
Receive(Tamb, message);
if (message is a request)
if (there are enough tape drives)
for each tape drive being allocated
{
fork a handler daemon;
send daemon mb # in message to requesting process;
update lists;
}
else
send a rejection message;
else if (message is a return)
{
update lists;
send an ack message;
}
else
ignore illegal messages;
}
Summary of user process actions:
- Send request to tape allocator.
- Receive message back giving mailbox(es) to use in communicating with
tape drive(s).
- Start sending/receiving with tape drive daemon(s).
- Close tape drives.
- Send message to tape allocator returning tape drive(s).
- On-line info:
http://http.cs.berkeley.edu/~tea/nachos/
.
- Root of Nachos source tree:
~kelliher/pub/cs42/nachos-3.4/
.
- Use a recursive copy to make one copy.
- nachos group: allows you to share your work.
- Do a recursive chown to make the group nachos for the
source tree.
- Before each editing session be sure to do the following:
lisp% umask 7
- Places to find documentation; printing and viewing Postscript files.
Thomas P. Kelliher
Thu Sep 19 17:55:49 EDT 1996
Tom Kelliher