RPC and Rendezvous INF4140 01.11.12 Lecture 9 Outline More on - - PowerPoint PPT Presentation

RPC and Rendezvous

INF4140

01.11.12

Lecture 9

Outline

More on asynchronous message passing Interacting processes with different patterns of communication Summary Remote procedure call (RPC) What is RPC Example: time server Rendezvous What is rendezvous Examples: buffer, time server Combinations of RPC, rendezvous and message passing Examples: bounded buffer, readers/writers

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 2 / 31

Interacting peers (processes): exchanging values example

Look at processes as peers. Example: Exchanging values Consider n processes P[0], . . . , P[n − 1], n > 1 Every process has a number – stored in a local variable v Goal: all processes knows the largest and smallest number. Look at different patterns of communication:

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 3 / 31

Interacting peers (processes): exchanging values example

Look at processes as peers. Example: Exchanging values Consider n processes P[0], . . . , P[n − 1], n > 1 Every process has a number – stored in a local variable v Goal: all processes knows the largest and smallest number. Look at different patterns of communication:

P1 P2 P3 P4 P5 P0 P0 P1 P2 P3 P4 P5 P0 P1 P2 P3 P4 P5

centralized symetrical ring shaped

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 3 / 31

Centralized solution

Process P[0] is the coordinator process: P[0] does the calculation The other processes sends their values to P[0] and waits for a reply.

P1 P2 P3 P4 P5 P0

Number of messages: (Just count the number of send:) P[0]: n − 1 P[1], . . . , P[n − 1]: (n − 1) × 1 Total: (n − 1) + (n − 1) = 2(n − 1) messages Number of channels: n

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 4 / 31

Centralized solution: code

chan v a l u e s ( i n t ) , r e s u l t s [ 1 . . n −1]( i n t s m a l l e s t , i n t l a r g e s t ) ; p r o c e s s P [ 0 ] { # c o o r d i n a t o r p r o c e s s i n t v = . . . ; i n t new , s m a l l e s t = v , l a r g e s t = v ; # i n i t i a l i z a t i o n # get v a l u e s and s t o r e the l a r g e s t and s m a l l e s t f o r [ i = 1 to n−1] { r e c e i v e v a l u e s ( new ) ; i f ( new < s m a l l e s t ) s m a l l e s t = new ; i f ( new > l a r g e s t ) l a r g e s t = new ; } # send r e s u l t s f o r [ i = 1 to n−1] send r e s u l t s [ i ] ( s m a l l e s t , l a r g e s t ) ; } p r o c e s s P[ i = 1 to n−1] { i n t v = . . . ; i n t s m a l l e s t , l a r g e s t ; send v a l u e s ( v ) ; r e c e i v e r e s u l t s [ i ] ( s m a l l e s t , l a r g e s t ) ; } # Fig . 7.11 i n Andrews ( c o r r e c t e d a bug )

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 5 / 31

Symmetrical solution

P0 P1 P2 P3 P4 P5

“Single-programme, multiple data (SPMD)”-solution: Each process executes the same code and shares the results with all other processes. Number of messages: n processes sending n − 1 messages each, Total: n(n − 1) messages. Number of channels: n

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 6 / 31

Symmetrical solution: code

chan v a l u e s [ n ] ( i n t ) ; p r o c e s s P[ i = 0 to n−1] { i n t v = . . . ; i n t new , s m a l l e s t = v , l a r g e s t = v ; # send v to a l l n−1 other p r o c e s s e s f o r [ j = 0 to n−1 s t j != i ] send v a l u e s [ j ] ( v ) ; # get n−1 v a l u e s # and s t o r e the s m a l l e s t and l a r g e s t . f o r [ j = 1 to n−1] { # j not used i n the loop r e c e i v e v a l u e s [ i ] ( new ) ; i f ( new < s m a l l e s t ) s m a l l e s t = new ; i f ( new > l a r g e s t ) l a r g e s t = new ; } } # Fig . 7.12 from Andrews

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 7 / 31

Ring solution

P0 P1 P2 P3 P4 P5

Almost symmetrical, except P[0], P[n − 2] and P[n − 1]. Each process executes the same code and sends the results to the next process (if necessary). Number of messages: P[0]: 2 P[1], . . . , P[n − 3]: (n − 3) × 2 P[n − 2]: 1 P[n − 1]: 1 2 + 2(n − 3) + 1 + 1 = 2(n − 1) messages sent. Number of channels: n .

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 8 / 31

Ring solution: code (1)

chan v a l u e s [ n ] ( i n t s m a l l e s t , i n t l a r g e s t ) ; p r o c e s s P [ 0 ] { # s t a r t s the exchange i n t v = . . . ; i n t s m a l l e s t = v , l a r g e s t = v ; # send v to the next process , P [ 1 ] send v a l u e s [ 1 ] ( s m a l l e s t , l a r g e s t ) ; # get the g l o b a l s m a l l e s t and l a r g e s t from P[ n−1] # and send them to P [ 1 ] r e c e i v e v a l u e s [ 0 ] ( s m a l l e s t , l a r g e s t ) ; send v a l u e s [ 1 ] ( s m a l l e s t , l a r g e s t ) ; }

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 9 / 31

Ring solution: code (2)

p r o c e s s P[ i = 1 to n−1] { i n t v = . . . ; i n t s m a l l e s t , l a r g e s t ; # get s m a l l e s t and l a r g e s t so far , # and update them by comparing them to v r e c e i v e v a l u e s [ i ] ( s m a l l e s t , l a r g e s t ) i f ( v < s m a l l e s t ) s m a l l e s t = v ; i f ( v > l a r g e s t ) l a r g e s t = v ; # forward the r e s u l t , and wait f o r the g l o b a l r e s u l t send v a l u e s [ ( i +1) mod n ] ( s m a l l e s t , l a r g e s t ) ; i f ( i < n−1) r e c e i v e v a l u e s [ i ] ( s m a l l e s t , l a r g e s t ) ; # forward the g l o b a l r e s u l t , but not from P[ n−1] to P [ 0 ] i f ( i < n−2) send v a l u e s [ i +1]( s m a l l e s t , l a r g e s t ) ; } # Fig . 7.13 from Andrews ( modified )

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 10 / 31

Message passing: Sumary

Message passing is well suited to programming filters and interacting peers (where processes communicates one way by one or more channels). May be used for client/server applications, but: Each client must have its own reply channel In general: two way communication needs two channels ⇒ many channels RPC and rendezvous are better suited for client/server applications.

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 11 / 31

Remote Procedure Call: main idea

CALLER CALLEE at computer A at computer B

• p foo(FORMALS); # declaration

... call foo(ARGS);

• ---->

proc foo(FORMALS) # new process ... <----- end; ...

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 12 / 31

RPC (cont.)

RPC combines some elements from monitors and message passing As ordinary procedure call, but caller and callee may be on different machines. Caller is blocked until the called procedure is done, as with monitor calls and synchronous message passing. Asynchronous programming is not supported directly.1 A new process handles each call. Potentially two way communication: caller sends arguments and receives return values.

1But in Creol . . . INF4140 (01.11.12) RPC and Rendezvous Lecture 9 13 / 31

RPC: module, procedure, process

Module: new program component – contains both procedures and processes.

module M headers

• f

exported

• p e r a t i o n s ;

body v a r i a b l e d e c l a r a t i o n s ; i n i t i a l i z a t i o n code ; p r oc e d u r e s f o r exported

• p e r a t i o n s ;

l o c a l pr o c e d u re s and p r o c e s s e s ; end M

Modules may be executed on different machines M has: Procedures and processes may share variables execute concurrently ⇒ must be synchronized to achieve mutex May only communicate with processes in M′ by procedures exported by M′

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 14 / 31

RPC: operations

Declaration of operation O:

• p O(formal parameters.) [ returns result] ;

Implementation of operation O: proc O(formal identifiers.) [ returns result identifier]{ declaration of local variables; statements } Call of operation O in module M: call M.O(arguments) Processes: as before.

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 15 / 31

Example: Time server (RPC)

Problem: Implement a module that provides timing services to processes in other modules. The time server defines two visible operations: get time() returns int – returns time of day delay(int interval) – let the caller sleep a given number of time units Multiple clients may call get time and delay at the same time ⇒ Need to protect the variables. The time server has an internal process that gets interrupts from a machine clock and updates tod.

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 16 / 31

Time server: code (RPC 1)

module TimeServer

• p

g e t t i m e () r e t u r n s i n t ;

• p

d e l a y ( i n t i n t e r v a l ) ; body i n t tod = 0 ; # time

• f

day sem m = 1 ; # f o r mutex sem d [ n ] = ( [ n ] 0 ) ; # f o r delayed p r o c e s s e s queue

• f

( i n t waketime , i n t p r o c e s s i d ) napQ ; # # when m == 1 , tod < waketime f o r delayed p r o c e s s e s proc g e t t i m e () r e t u r n s time { time = tod ; } proc d e l a y ( i n t i n t e r v a l ) { P(m) ; # assume unique myid and i [ 0 , n−1] i n t waketime = tod + i n t e r v a l ; i n s e r t ( waketime , myid ) at a p p r o p r i a t e p l a c e i n napQ ; V(m) ; P( d [ myid ] ) ; # Wait to be awoken } p r o c e s s Clock . . . . . . end TimeServer

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 17 / 31

Time server: code (RPC 2)

p r o c e s s Clock { i n t i d ; s t a r t hardware timer ; w h i l e ( t r u e ) { wait f o r i n t e r r u p t , then r e s t a r t hardware timer tod = tod + 1 ; P(m) ; # mutex w h i l e ( tod >= s m a l l e s t waketime

• n napQ)

{ remove ( waketime , i d ) from napQ ; V( d [ i d ] ) ; # awake p r o c e s s } V(m) ; # mutex } } end TimeServer # Fig . 8.1

• f

Andrews

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 18 / 31

Rendezvous

RPC: Offers inter module communication Synchronization must be programmed explicitly Rendezvous: Known from the language Ada (US DoD) Combines communication and synchronization between processes No new process made when a call is made. Does ‘rendezvous’ with existing process Operations are executed one at the time synch send and receive may be considered as primitive rendezvous.

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 19 / 31

Rendezvous: main idea

CALLER CALLEE at computer A at computer B

• p foo(FORMALS); # declaration

... ... # existing process call foo(ARGS);

• ---->

in foo(FORMALS)

• >

BODY; <----- ni ...

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 20 / 31

Rendezvous: module declaration

module M

• p O1 ( types ) ;

. . .

• p On ( types ) ;

body p r o c e s s P1 { v a r i a b l e d e c l a r a t i o n s ; w h i l e ( t r u e ) i n O1 ( f o r m a l s ) and B1 − > S1 ; . . . [ ] On ( f o r m a l s ) and Bn − > Sn ; n i } . . . other p r o c e s s e s end M

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 21 / 31

Rendezvous: syntax of expressions

Call:

c a l l Oi (expr1, . . . , exprm ) ;

Input statement, multiple guarded expressions:

i n O1(v1, . . . vm1) and B1 − > S1 ; . . . [ ] On(v1, . . . vmn) and Bn − > Sn ; n i

The guard consists of: and Bi – synchronization expression (optional) Si – statements (one or more) The variables v1, . . . , vmi may be referred by Bi and Si may read/write to them.

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 22 / 31

Rendezvous: semantics of input statement

Consider the following:

i n . . . [ ] Oi(vi, . . . , vmi ) and Bi − > Si ; . . . n i

The guard succeeds when Oi is called and Bi is true (or omitted). Execution of the in statement: Delays until a guard succeeds If more than one guard succeed, the oldest call is served Values are returned to the caller The the call- and in statements terminates

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 23 / 31

Example: bounded buffer (rendezvous)

module BoundedBuffer

• p

d e p o s i t ( elem ) , f e t c h ( r e s u l t elem ) ; body p r o c e s s B u f f e r { elem buf [ n ] ; i n t f r o n t = 0 , r e a r = 0 , count = 0 ; w h i l e ( t r u e ) i n d e p o s i t ( item ) and count < n − > buf [ r e a r ] = item ; count++; r e a r = ( r e a r +1) mod n ; [ ] f e t c h ( item ) and count > 0 − > item = buf [ f r o n t ] ; count −−; f r o n t = ( f r o n t +1) mod n ; n i } end BoundedBuffer # Fig . 8.5

• f

Andrews

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 24 / 31

Example: time server (rendezvous)

module TimeServer

• p

g e t t i m e () r e t u r n s i n t ;

• p

d e l a y ( i n t ) ; # Waketime as argument

• p

t i c k ( ) ; # c a l l e d by the c l o c k i n t e r r u p t h a n d l e r body p r o c e s s Timer { i n t tod = 0 ; s t a r t timer ; w h i l e ( t r u e ) i n g e t t i m e () r e t u r n s time − > time = tod ; [ ] d e l a y ( waketime ) and waketime <= tod − > s k i p ; [ ] t i c k () − > { tod++; r e s t a r t timer ; n i } end TimeServer # Fig . 8.7

• f

Andrews

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 25 / 31

RPC, rendezvous and message passing

We do now have several combinations: invocation service effect call proc procedure call (RPC) call in rendezvous send proc dynamic process creation send in asynchronous message passing

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 26 / 31

RPC, rendezvous and message passing

We do now have several combinations: invocation service effect call proc procedure call (RPC) call in rendezvous send proc dynamic process creation send in asynchronous message passing in addition (not in Andrews) asynchronous procedure call, wait-by-necessity, futures

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 26 / 31

Rendezvous, message passing and semaphores

Comparing input statements and receive:

in O(a1, . . . ,an) ->v1=a1,. . . ,vn=an ni ⇐ ⇒ receive O(v1, . . . , vn)

Comparing message passing and semaphores: send O() and receive O() ⇐ ⇒ V(O) and P(O)

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 27 / 31

Example: Bounded buffer (again)

module BoundedBuffer

• p

d e p o s i t ( elem ) , f e t c h ( r e s u l t elem ) ; body elem buf [ n ] ; i n t f r o n t = 0 , r e a r = 0; # l o c a l

• p e r a t i o n

to s i m u l a t e semaphores

• p empty ( ) ,

f u l l ( ) , mutexD ( ) , mutexF ( ) ; send mutexD ( ) ; send mutexF ( ) ; # i n i t . ” semaphores ” to 1 f o r [ i = 1 to n ] # i n i t . empty−”semaphore ” to n send empty ( ) ; proc d e p o s i t ( item ) { r e c e i v e empty ( ) ; r e c e i v e mutexD ( ) ; buf [ r e a r ] = item ; r e a r = ( r e a r +1) mod n ; send mutexD ( ) ; send f u l l ( ) ; } proc f e t c h ( item ) { r e c e i v e f u l l ( ) ; r e c e i v e mutexF ( ) ; item = buf [ f r o n t ] ; f r o n t = ( f r o n t +1) mod n ; send mutexF ( ) ; send empty ( ) ; } end BoundedBuffer # Fig . 8.12

• f

Andrews

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 28 / 31

The primitive ?O in rendezvous

New primitive on operations, similar to empty(. . . ) for condition variables and channels. ?O means number of pending invocations of operation O. Useful in the input statement to give priority: in O1 . . . -> S1; [ ] O2 . . . and ?O1 == 0 -> S2; ni Here O1 has a higher priority than O2.

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 29 / 31

Readers and writers

module ReadersWriters

• p

read ( r e s u l t types ) ; # uses RPC

• p

w r i t e ( types ) ; # uses rendezvous body

• p

s t a r t r e a d ( ) , endread ( ) ; # l o c a l

• ps .

. . . database (DB ) . . . ; proc read ( v a r s ) { c a l l s t a r t r e a d ( ) ; # get read a c c e s s . . . read v a r s from DB . . . ; send endread ( ) ; # f r e e DB } p r o c e s s Writer { i n t nr = 0; w h i l e ( t r u e ) i n s t a r t r e a d ( ) − > nr++; [ ] endread ( ) − > nr −−; [ ] w r i t e ( v a r s ) and nr == 0 − > . . . w r i t e v a r s to DB . . . ; n i } end ReadersWriters

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 30 / 31

Readers and writers: prioritize writers

module ReadersWriters

• p

read ( r e s u l t types ) ; # uses RPC

• p

w r i t e ( types ) ; # uses rendezvous body

• p

s t a r t r e a d ( ) , endread ( ) ; # l o c a l

• ps .

. . . database (DB ) . . . ; proc read ( v a r s ) { c a l l s t a r t r e a d ( ) ; # get read a c c e s s . . . read v a r s from DB . . . ; send endread ( ) ; # f r e e DB } p r o c e s s Writer { i n t nr = 0; w h i l e ( t r u e ) i n s t a r t r e a d ( ) and ? w r i t e == 0 − > nr++; [ ] endread ( ) − > nr −−; [ ] w r i t e ( v a r s ) and nr == 0 − > . . . w r i t e v a r s to DB . . . ; n i } end ReadersWriters

INF4140 (01.11.12) RPC and Rendezvous Lecture 9 31 / 31