Review: message-passing
z
RPC and Rendezvous
z
Uses channels for process interaction
Types of Interaction patterns
–
–
–
filter
client/server
interacting peers
Lesson 07
COMP5126
2
MPD
z
z
MPD II
z
Can declare a communication “path”
op name(fields/formats)
Communication patterns:
Invoke
Service
–
–
–
z
effect
z
call
proc
procedure call
send
proc
create a thread
send
receive
asynchronous
message passing
call
in
rendezvous
3
resource — similar to a “class”
Consists of spec and body parts
Can separate if want to restrict visibility, e.g.:
resource abc
# specification, visible operations
body abc (formal args)
# operations definitions
end abc
4
MPD III
z
MPD IV
z
op type
z
maps to one of three statements in the body:
–
–
–
declare the op’s in the resource specification:
resource sample()
op values(int, int);
op name (formal arguments)
5
start with one resource — main
can create other resources
can place them on different machines
z
proc — becomes either a procedure call or creates
a new thread
receive — an existing thread receives the operation
in — rendezvous with an existing process, implies
synchronisation
z
define its implementation in the body; 3 types:
as a proc
body
proc values(int x, int y) { # a procedure
... code for the proc ...
}
z
6
as a receive
body
process zap {
... some code here...
receive values(my_x, my_y) # a channel
... some more code here...
}
1
MPD V
z
MPD VI
a reference to an instance
created dynamically
–
process zap {
while (true) {
in values(x,y) -> # in statement
..code for in arm
[] else ->
..else arm
ni
}
7
capability variable used to refer to resources in another resource
z
as an input statement:
–
E.g.: declare a resource spec and a body:
z
resource Sample
...
body Sample(int, int, int)
process ...
And in the specification of another resource:
z
resource zap
cap Sample scap # a capability for an instance of Sample
Body zap()
...
scap = create Sample(i, numProcs, numRounds)
– creates an instance of sample, assigns its capability to scap
8
MPD VII
z
Virtual machines
–
–
–
z
RPC and Rendezvous: Overview
Aids distributed memory programming
created dynamically
establishes a different address space (i.e., does a Unix fork)
z
Message Passing tools
z
Distributed Systems
–
To distribute instances on different physical machines:
–
vc = create vm() on “shade" # create an address space
# on another machine
scap = create Sample(i, numProcs, numRounds) on vc
z
z
z
–
–
Can now use scap to send messages to op’s defined within Sample
myresource() — analogous to self in Java. Returns a capability for
the resource in which the function is called.
Can also create an array of capabilities:
z
cap Sample scap[numSamples];
z
Can then create multiple instances of Sample:
for [i = 1 to numSamples] {
scap[i] = create Sample(i, numProcs, numRounds);
}
9
z
clients and servers can “switch” roles — a process
can be a “client” when contacting other servers, and
can also be contacted (as a “server”) by other
processes
Remote Procedure Call
z
Remote Procedure Call (RPC): the “server” is
passive until contacted by the client
Rendezvous: the “server” is active. Communication
between client and server then causes a rendezvous
between two active entities.
client makes “call” to proc zap
–
–
z
–
–
–
z
OS delivers the message containing
the args
a new thread executes the
procedure
reply message containing results is
constructed
sent to client
Strictly speaking:
–
–
12
OS (or runtime) creates a message
containing arguments
client is blocked on receive
awaiting reply
server handles the call
–
11
contain clients and servers
servers — passive entity, often multi-threaded
clients — active entity, initiate communication with
servers
10
RPC and Rendezvous
z
MPD — create vm’s on nodes, create resources on vm’s
RPC is synchronous
mirrors language procedure mechanism — client does not do
anything else while procedure is executing
2
Rendezvous
z
Server is an active entity
–
–
z
z
existing process
does not create a new thread to
handle a call
z
–
–
OS (or runtime) delivers message
to server
Message not received until server
“gets to” in zap()
Reply message sent when server
completes body of zap()
z
z
Both server and client continue
executing after reply message
is sent
13
concurrent read’s & write’s allowed, as above
exclusive read’s & write’s
–
–
synchronized read and write methods with the object (Java)
mutex semaphores (MPD, Pthreads)
14
Database Server using RPC
z
–
–
z
z
If RPC only:
–
need to synchronise read’s and write’s (as above)
need to keep track of number of reader’s
need to decide on reader’s preference or writer’s preference or
neither
–
Implication: RPC is a communication mechanism ONLY.
–
z
RPC and Rendezvous: Readers/Writers
True reader’s and writer’s (multiple simultaneous readers
possible)
–
–
Internal synchronisation is still necessary for solutions to problems
such as readers/writers
z
MPD RPC
declare a proc
– call it — Synchronous RPC
call zap(x, y);
– client is blocked until (implicit) reply comes back
–
15
Each RPC call to the exported read() or write()
procedures creates a thread
Each thread then calls internal procedures to gain
permission to access the database (and to release the
database)
Need synchronisation among the threads to satisfy the
RW invariant (need semaphores, etc.)
If Rendezvous only:
–
–
Operations are served by pre-existing threads
Implies that the number of concurrent reads, for example,
is limited to the number of pre-existing threads
16
resource ReadersWriters
op read(result result types); # uses RPC
op write(value types);
# uses rendezvous
body
op startread(), endread();
# local operations
storage for the database
proc read(results) {
call startread();
# get read permission
read the database;
send endread();
# release read permission
}
process Writer {
int nr = 0;
while (true) {
in startread() -> nr = nr + 1;
[] endread() -> nr = nr - 1;
[] write( values ) and nr == 0 ->
write the database;
ni
}
} # Writer
end ReadersWriters
E.g.: Readers/Writers
z
z
When both are present, can use Rendezvous to
control access to the database and RPC to create the
threads needed for the multiple readers (Fig. 8.13,
page 388)
Semantics of in:
–
–
z
17
Clients do read and write
Server module
local data
proc read() {
...
}
proc write() {
...
}
Server sequence
–
z
E.g.: Database Server using RPC
only one of the branches can be active at a time ⇒
implicit exclusion
if more than one branch can be active (i.e., has a pending
message), it is non-deterministic which will go next
write() operation is encapsulated within the in;
thus, when the write() is being executed, no reader
can begin startread().
18
3
Replicated File Server
z
z
z
Each server can have a complete set of files, or
Each server maintains some subset of the files, and each file
is present at least two places (redundancy)
Client can connect to “nearest” Server
–
–
Server then asks other Servers for file, if not present locally
Actual location of files can be made transparent to the Clients
z
Lets assume here that each
server has one file and a
client connects directly to
its server
19
21
20
proc read(results) {
read from local copy of file and return results;
} # read
proc write(values) {
if (use == READ)
return with error: file not opened for writing;
write values into local copy of file;
# concurrently update all remote copies
co [i = 1 to n st i != myid]
call FileServer[i].remote_write(values);
oc
} # write
proc remote_write(values) { # called by servers
write values into local copy of file;
} # remote_write
process Lock {
int nr = 0, nw = 0;
while (true) {
## RW: (nr == 0 Ú nw == 0) ^ nw <= 1
in startread() and nw == 0 -> nr = nr + 1;
[] endread() -> nr = nr - 1;
[] startwrite() and nr == 0 and nw == 0 ->
nw = nw + 1;
[] endwrite() -> nw = nw + 1;
ni
}
}
end FileServer
module FileServer[myid = 1 to n]
type mode = enum(READ, WRITE);
op open(mode), close(),
# client operations
read(result result types), write(value types);
op startwrite(), endwriter(), # server operations
remote_write(value types);
body
op startread(), endread(); # local operations
mode use; declarations for file buffers;
proc open(m) {
if (m == READ) {
call startread(); # get local read lock
use = READ;
} else { # mode assumed to be WRITE
# get write locks for all copies
for [i = 1 to n]
call FileServer[i].startwrite();
use = WRITE;
}
} # open
proc close() {
if (use == READ) # release local read lock
send endread();
else # use == WRITE, so release all write locks
for [i = 1 to n]
send FileServer.endwrite();
} # close
Remark: Replicated File Server
z
z
Only one Lock process per fileserver ⇒ implicit
exclusion within that file server
Write locks the entire file system(!)
–
–
z
in semantics prevents a particular server from granting
the startwrite unless/until there are not readers on that file
server
some servers will then be “write-blocked” while other
servers finish handling readers
“Write-through” cache, with write-throughs done
concurrently. Happens with every write to the file.
22
Summary
z
z
z
z
RPC and Rendezvous are communication
mechanisms
Each RPC call to the exported procedures creates a
thread
Whereas, each rendezvous call results in handling
by an existing thread
Within the called (server) module, access of
multiple threads to the module’s data still need to be
protected using synchronisation mechanisms
23
4