Lecture 27
Review/Preview
RPC (RMI) call foo(...) proc foo(...) # new thread
body
end
rendezvous call foo(...) ...; # existing process
in foo(...) -> body ni;
...
remarks on CSP as inspiration for rendezvous
today: details of rendezvous using a series of examples
multiple primitives
readers/writers examples
Rendezvous in SR -- examples of servers, mostly from Section 8.2.2
(1) basic primitive in opname(formals) -> body ni
provides a "remote subroutine"; programmed in Ada as
accept opname(formals) do body end
(2) multiple entries -- distributed file system example in Section 8.1.3
in readblk(...) -> ...
[] writeblk(...) -> ...
ni
this services invocations in FIFO order
(3) delay based on local state -- synchronization expression (and or st)
in request() and avail > 0 -> avail--; ...
[] release() -> avail++; ...
ni
(4) delay based on arguments
in getforks(id) and not (eating[i+1] or eating[i-1]) -> eating[i] := true
[] relforks(id) -> eating[i] := false
ni
(5) scheduling based on arguments -- scheduling expression (by)
in request(time) and free by time -> free := false
[] release() -> free := true
ni
NB: Ada supports only (1)-(3) using select and accept;
you cannot directly do (4) and (5)
(6) priority to an operation
?opname -- number of pending invocations
in op1() -> S1
[] op2() and ?op1 = 0 -> S2 # gives priority to op1
ni
(7) simple receive
in opname(formals) -> vars := formals ni === receive opname(vars)
(8) simple barrier
in barrier() and ?barrier = N ->
fa i := 1 to n-1 -> receive barrier() af
ni
this waits for there to be N invocations; then the first
is removed from the op queue (and held on to); then the next
n-1 invocations are received (and the calls complete);
then the first invocation is completed (at the ni)
how could we get a FIFO reply order?
put a reply statement in front of the for-all statement,
. or put the ni at the end of the first line
Summary of the Core of SR
resources and globals -- more next time
operations -- op name(formals)
table of invocation/service/effect one more time
receive is a special case of in
semaphores are a special case of send/receive
return means "reply and exit"; reply means "reply and keep going"
Readers/Writers Examples -- Section 8.4
(1) encapsulated databased
block digram of the problem and outline of the ReadersWriters
module in Figure 8.13.
implementing the module:
using Java -- see Chapter 5 and Web site
using SR -- go over transparency for Figure 8.13
(2) replicated files
interaction pattern -- drew diagram in Figure 8.14
has client/server interaction AND interacting peers (between servers)
server operations -- open, close, read, write, ...
for read, lock local copy only
for write, lock ALL copies (a writer can read too)
go over code in Figure 8.15
this shows one way to program a very common interaction pattern
variation on this locking scheme -- weighted voting
I describe the idea briefly. See pp. 392-93.