Meldingsutveksling. Martin Steffen 1. University of Oslo, Norway INF3140. Høst 2007

Transkript

1 Martin Steffen 1 University of Oslo, Norway INF3140 Høst 2007

2 University of Oslo, Norway INF3140 Høst Martin Steffen 1 The following slides come at week 8. This lection opens the second part of the course, where part I is about shared-variable concurrency and the second one is about message passing ( kommunikasjon ) as it was called, but there is also some stuff about synchronous message passing. In autum 2007, there was an introduction about Java threading. The focus here is on asynchronous message passing. There is a connection between asynchronous message passing (which is new here) and the semaphore s P and V operations, which have been treated in the lecture. Send is like V (which is up) and receive is like P (down). The generalization is that now there are values transmitted. However, the parallel is not too convincing, as the purpose of a channel (apart for transmission) is different: a channel is not a data structure to assure mutex (with the additional benefit of transmitting information. Well, on the other hand, Andrews has a point, not all semaphores are for mutex. He claims also a duality between monitors and message passing.

3 Perspektiv, program Perspektiv på kurset: Del I: programmering med delte variable Del II: distribuert programmering, unntatt CSP-delen Dagens program: asynkron og synkron meldingsutveksling Samtidig vs. distribuert programmering Asynkron meldingsutveksling: kanaler, meldinger, primitiver Eksempel: Filtre og sorteringsnettverk Fra monitor til klient tjener-applikasjoner Sammenligning av meldingsutveksling og monitorer Om synkron meldingsutveksling Martin Steffen (UiO) / 31

4 Perspektiv, program Perspektiv, program Perspektiv på kurset: Del I: programmering med delte variable Del II: distribuert programmering, unntatt CSP-delen Dagens program: asynkron og synkron meldingsutveksling Samtidig vs. distribuert programmering Asynkron meldingsutveksling: kanaler, meldinger, primitiver Eksempel: Filtre og sorteringsnettverk Fra monitor til klient tjener-applikasjoner Sammenligning av meldingsutveksling og monitorer Om synkron meldingsutveksling Del II av kurset begynner, tilsvarer Part 2 i Andrews. The program in this section does not cover all of Chapter 7 (message passing). A little is taken also from the intro to part II (which is outside chapter 7). Who knows real live message passing? What s real-live (asynchronous) message passing?

5 Delt minne vs. distribuert minne Tradisjonelle systemarkitekturer har ett minne som deles : Flere prosessorer aksesserer samme fysiske minne Eksempel: kraftig filtjener med flere prosessorer på ett hovedkort Distribuerte minne-arkitekturer er nå vanlig: Prosessorer har privat minne og kommuniserer vha. nettverk Eksempler: Multicomputer: asynkr. multi-prosessor med distribuert minne (typisk i ett kabinett) Arbeidsstasjonsklynger: PC er i lokalnett Grid-system: maskiner på internett, ressursdeling Martin Steffen (UiO) / 31

6 Delt minne vs. distribuert minne Delt minne vs. distribuert minne Tradisjonelle systemarkitekturer har ett minne som deles : Flere prosessorer aksesserer samme fysiske minne Eksempel: kraftig filtjener med flere prosessorer på ett hovedkort Distribuerte minne-arkitekturer er nå vanlig: Prosessorer har privat minne og kommuniserer vha. nettverk Eksempler: Multicomputer: asynkr. multi-prosessor med distribuert minne (typisk i ett kabinett) Arbeidsstasjonsklynger: PC er i lokalnett Grid-system: maskiner på internett, ressursdeling Hybrider finnes. Besides that, it all is also a question of the level of abstraction. E.g., DSM (distributed shared memory) means that one implements the illusion of a shared memory on top of a distributed hardware. (Chapter 10). Why would one want that?

7 Samtidig vs. distribuert programmering Samtidig programmering (eng. concurrent programming): Prosessorene deler ett minne Prosesser kommuniserer ved lesing og skriving av delte variable Distribuert programmering: Minne er distribuert prosessene kan ikke dele variable (direkte) Prosesser kommuniserer ved å sende og motta meldinger over delte kanaler eller (i senere forelesninger) kommunikasjon ved RPC og rendezvous Martin Steffen (UiO) / 31

8 Samtidig vs. distribuert programmering Samtidig vs. distribuert programmering Samtidig programmering (eng. concurrent programming): Prosessorene deler ett minne Prosesser kommuniserer ved lesing og skriving av delte variable Distribuert programmering: Minne er distribuert prosessene kan ikke dele variable (direkte) Prosesser kommuniserer ved å sende og motta meldinger over delte kanaler eller (i senere forelesninger) kommunikasjon ved RPC og rendezvous RPC and rendezvous comes in Chapter 8. One has to be a bit careful with the terminology of message passing, to start with. For instance, often people in OO speak of method calls also of message passing. That s ok, as such, but it does not mean, that, for instance Java, from the lession before belongs to the message passing kind of concurrency model in the sense presented here. The differentiation Andrews draws between chapter 7 and 8 is that here, the channels are one-directed.. For RPC, they would be two-way (call-return). And for rendez-vouz?

9 Asynkron meldingsutveksling: kanal-abstraksjonen Kanal : abstraksjon av det fysiske kommunikasjonsnettverket Enveis fra sender(e) til mottaker(e) Ubegrenset FIFO-kø av ventende meldinger Bevarer meldingsordning Atomisk adgang Feilfri Typet Varianter: feil mulig, utypet,... Martin Steffen (UiO) / 31

10 4. If buffers and channels are the same: Why do channels play a much more important role in concurrent programming than buffers in sequential programming? What if the channel is over a network? Asynkron meldingsutveksling: kanal-abstraksjonen Asynkron meldingsutveksling: kanal-abstraksjonen Kanal : abstraksjon av det fysiske kommunikasjonsnettverket Enveis fra sender(e) til mottaker(e) Ubegrenset FIFO-kø av ventende meldinger Bevarer meldingsordning Atomisk adgang Feilfri Typet Varianter: feil mulig, utypet,... Ser på én (Andrews ) av flere mulige abstraksjoner. Forklar ord: asynkron, synkron (senere i pensum), FIFO. Mottaker=sender er mulig (brukes for å putte meldinger tilbake). Syntaks og semantikk er neste punkt. Prosesser kommuniserer over kanaler. Note that synchrone is not what is the keyword synchonized in Java. Apart from that that one has to take care also with the word synchronous system etc. 1. What kind of channels does one know? 2. pipes in Unix? Sockets? 3. If one thinks of a channels as a data type (or is a channel active?): what ca one do with a channel? What s the difference between a channel and a buffer? (not much actually).

11 Asynkron meldingsutveksling: primitiver Kanaldeklarasjon: chan c(type 1 id 1,..., type n id n ); Meldinger: n-tuppel av verdier, av de relevante typer Primitiver for kommunikasjon: send c(expr 1,...,expr n ); Ikke-blokkerende, dvs. asynkron receive c(var 1,...,var n ); Blokkerende: mottaker venter til melding er sendt på kanal empty(c); Sann hvis kanal tom P 1send c receive P 2 Martin Steffen (UiO) / 31

12 Asynkron meldingsutveksling: primitiver Asynkron meldingsutveksling: primitiver Kanaldeklarasjon: chan c(type1 id1,..., typen idn); Meldinger: n-tuppel av verdier, av de relevante typer Primitiver for kommunikasjon: send c(expr1,...,exprn); P1 send Ikke-blokkerende, dvs. asynkron receive c(var1,...,varn); c Blokkerende: mottaker venter til melding er sendt på kanal receive P2 empty(c); Sann hvis kanal tom Forklar figurens notasjon. Kommentarer: Typer, antall felt i meldinger må stemme med kanal (Feltnavnene kan utelates) Sammenlign empty med monitor og bet.var.: empty(cv); En prosess kan sende til seg selv. Kommenter at flere prosesser kan konkurrerer om å motta/sende på samme kanal. Mulig figur (a shared channel) Can a process be a sender an a receiver of the same channel? What s the comparison with the monitor/condition variables?

13 Eksempel: meldingsutveksling A send foo receive B chan foo ( i nt ) ; process A { process B { # t i l s v a r e r : send foo ( 1); r e ceive foo ( x ) ; # x =? send foo ( 2); r e ceive foo ( y ) ; # y =? Martin Steffen (UiO) / 31

14 Eksempel: meldingsutveksling Eksempel: meldingsutveksling A send receive foo B chan foo ( i nt ) ; process A { process B { # t i l s v a r e r : send foo (1 ); r e ceive foo ( x ) ; # x =? send foo (2 ); r e ceive foo ( y ) ; # y =? Her: melding = heltall (integer) Har utelatt feltnavn i deklarasjonen.

15 Eksempel: delt kanal A1 send foo receive B send A2 chan foo ( i nt ) ; process A1 { process B { # t i l s v a r e r : send foo ( 1); r eceive foo (x ) ; # (x, y) =? r eceive foo (y ) ; # e l l e r (x, y) =? process A2 { send foo ( 2); Martin Steffen (UiO) / 31

16 Eksempel: meld.utv. med ikkedeterminisme A1 send foo receive B send A2 chan foo ( i nt ) ; process A1 { process B { # t i l s v a r e r : send foo ( 1); r eceive foo (x ) ; # (x, y) := (1,2) r eceive foo (y ) ; # e l l e r (x, y) := (2,1) process A2 { send foo ( 2); Martin Steffen (UiO) / 31

17 Eksempel: meld.utv. med ikkedeterminisme Eksempel: meld.utv. med ikkedeterminisme A1 send receive foo B send A2 chan foo ( i nt ) ; process A1 { process B { # t i l s v a r e r : send foo (1 ); receive foo (x ) ; # (x, y ) := (1,2) receive foo (y ) ; # eller (x, y ) := (2,1) process A2 { send foo (2 ); To kanaler. Prosess B som før. Kommenter ikkedeterminisme. Race condition. A similiar (actually the same) effect has been seen with shared variables! Indeed, the channel (which contains at most one value) is a shared variable, in some sense.

18 Asynkron meldingsutveksling og semaforer Sammenligning med generell semafor: kanal semafor send V receive P Antall meldinger i køen = verdien til semaforen (Ser bort fra innholdet i meldingene) Martin Steffen (UiO) / 31

19 Asynkron meldingsutveksling og semaforer Asynkron meldingsutveksling og semaforer Sammenligning med generell semafor: kanal semafor send V receive P Antall meldinger i køen = verdien til semaforen (Ser bort fra innholdet i meldingene) Generell semafor: verdi = positivt heltall Kommenter: venting og blokkering. Semaphors have been treated in Chap 4 (synchr., avoid busy waiting). In this book, the semaphores are from non-negative integers. Entry (=P) = minus 1. One has to be careful. The number counts the free resources. Sometimes negative numbers are used to count, how many processes are waiting on a semaphore. In the comparison with the channels here, there is no analogon (it would be the number of processes being blocked for a receive (which implies parallel processes sharing an input channel. A difference between channels and semaphores for me is also that a (binary) semaphore starts with a value 1 (entry ok). A channel typically starts with 0 (= empty). In the producer-consumer implementation (with 2 counting semaphores), this of course, corresponds to a bounded channel. If the channel were unbounded, then one had only one sem., namely for the reader, which is the blocking one. One crucual difference of the the semaphore use for mutex and for the channels here is, that semaphores (in the mutex way) used to synchronzed access. But for channesl (and producer-consumer), the channel ends are typically not shared!

20 Filtre: enveisinteraksjon Et filter F er en prosess som mottar meldinger på innputt-kanaler, sender meldinger på utputt-kanaler, og der utputt er en funksjon av innputt (og initialtilstanden). in 1 receive send out 1. F. receive send in n out m Et filter spesifiseres som et predikat. Noen beregninger kan naturlig ses som en komposisjon av filtre. Martin Steffen (UiO) / 31

21 Examples Filtre: enveisinteraksjon Filtre: enveisinteraksjon Et filter F er en prosess som mottar meldinger på innputt-kanaler, sender meldinger på utputt-kanaler, og der utputt er en funksjon av innputt (og initialtilstanden). in1 out1 receive send. F. receive send inn outm Et filter spesifiseres som et predikat. Noen beregninger kan naturlig ses som en komposisjon av filtre. META: Filtre er et lite løfterikt begrep tone det ned. Predikat her: logisk formel som skal holde, omtaler kanalene, eksempel kommer. Funksjon: kan ikke ha globale variable i et filter.

22 Eksempel: filter for strømfletting Problem: Flette to sorterte innputt-strømmer til én sortert strøm. Prosess Merge med innputt-kanaler in 1 og in 2 og output-kanal out: in 1 : in 2 : Spesialverdi EOS markerer slutten på en strøm. Definer: n : antall verdier sent til out. sent[i] : i te verdi sendt til out. Følgende skal holde når Merge avslutter: out : in 1 og in 2 er tomme sent[n + 1] = EOS i : 1 i < n ( sent[i] sent[i + 1] ) verdier sendt til out er permutasjon av v. fra in 1 og in 2 Martin Steffen (UiO) / 31

23 Examples Eksempel: filter for strømfletting Eksempel: filter for strømfletting Problem: Flette to sorterte innputt-strømmer til én sortert strøm. Prosess Merge med innputt-kanaler in1 og in2 og output-kanal out: in1 : in2 : Spesialverdi EOS markerer slutten på en strøm. Definer: n : antall verdier sent til out. sent[i] : i te verdi sendt til out. Følgende skal holde når Merge avslutter: in1 og in2 er tomme sent[n + 1] = EOS i : 1 i < n ( sent[i] sent[i + 1] ) out : verdier sendt til out er permutasjon av v. fra in1 og in2 Spesialverdi er ikke en vanlig verdi i definisjon/regler. META: dette er nokså basalt, men illustrerer filter-idéen... That actually works like the sequential merge sort.

24 Eksempel: Prosessen Merge chan in1 ( i nt ), in2 ( i n t ), out ( i nt ) ; process Merge { i nt v1, v2 ; r e ceive in1 ( v1 ) ; r e ceive in2 ( v2 ) ; while ( v1!= EOS and v2!= EOS) { i f ( v1 <= v2 ) { send out ( v1 ) ; r eceive in1 ( v1 ) ; e l s e # ( v1 > v2) { send out ( v2 ) ; r eceive in2 ( v2 ) ; # l e s de f oerste to # innputt v e r d i e r # send minste v erdi t i l out og gjenta # konsumer r es ten av ikke tom input kan while ( v2!= EOS) { send out ( v2 ) ; r e ceive in2 ( v2 ) ; while ( v1!= EOS) { send out ( v1 ) ; r e ceive in1 ( v1 ) ; send out (EOS ) ; # legg t i l s p e s i a l v e r d i paa out Martin Steffen (UiO) / 31

25 Examples Eksempel: Prosessen Merge Eksempel: Prosessen Merge chan in1 ( i nt ), in2 ( i n t ), out ( i nt ) ; process Merge { int v1, v2 ; receive in1 ( v1 ) ; # les de foerste to receive in2 (v2 ) ; # innputt verdier # send minste verdi t i l out og gjenta while ( v1!= EOS and v2!= EOS) { i f ( v1 <= v2 ) { send out ( v1 ) ; receive in1 ( v1 ) ; e l s e # ( v1 > v2) { send out ( v2 ) ; receive in2 ( v2 ) ; # konsumer r esten av ikke tom input ka while ( v2!= EOS) { send out ( v2 ) ; receive in2 ( v2 ) ; while ( v1!= EOS) { send out ( v1 ) ; receive in1 ( v1 ) ; send out (EOS ) ; # legg ti l spesialverdi paa out Kommenter deklarasjonen av 3 kanaler. Merk at løkkene gjenoppretter tilstanden i variablene for hvert gjennomløp. Siste del er enklere enn i Andrews (men korrekt). Her er Andrews versjon:

26 Eksempel: Sorteringsnettverk Lager nå nettverk som sorterer n tall. Bruker en samling Merge-prosesser med tabeller av delte input- og output-kanaler. Alternativer i tilordning av kanaler til prosesser: statisk tilordning, dvs. faste kanaler dynamisk tilordning ved kjøretid. Martin Steffen (UiO) / 31

27 Examples Eksempel: Sorteringsnettverk Eksempel: Sorteringsnettverk Lager nå nettverk som sorterer n tall. Bruker en samling Merge-prosesser med tabeller av delte input- og output-kanaler. Alternativer i tilordning av kanaler til prosesser: statisk tilordning, dvs. faste kanaler dynamisk tilordning ved kjøretid. Tegn figur 7.3 fra Andrews. Her er det n 1 prosesser; eksempel: 16 tall, prosesser log 2 n bredde; eksempel: log 2 16 = 4 Mange meldinger sendt passer best for større oppgaver enn sammenligning. (Må være parallelliserbar.) Compare also the complexity of linear merge sort (recursive/divide and conquer sorting algorithm).

28 Klient-tjener-applikasjoner vha. meldinger Tjener: prosess som gjentatte ganger håndterer forespørsler fra klient-prosesser (eng.: server, client, request). Programmerer klienter og tjenere med asynkron meldingsutveksling. chan request ( i n t clientid,...), r eply [ n ] (... ) ; k l i e n t nr. i t j e n er i nt id ; # klient id. while ( true ) { # tjener loekke send request ( i, args ) ; r e ceive request ( id, vars ) ;.. r e ceive r eply [ i ] ( vars ) ; send r eply [ id ]( r e s u l t s ) ; Martin Steffen (UiO) / 31

29 Examples Klient-tjener-applikasjoner vha. meldinger Klient-tjener-applikasjoner vha. meldinger Tjener: prosess som gjentatte ganger håndterer forespørsler fra klient-prosesser (eng.: server, client, request). Programmerer klienter og tjenere med asynkron meldingsutveksling. chan request ( i n t clientid,...), r eply [ n ] (... ) ; klient nr. i tjener int id ; # klient id. while ( true ) { # tjener loekke send request ( i, args ) ; receive request ( id, vars ) ;.. r e ceive r eply [ i ] ( vars ) ; send r eply [ id ] ( r e s u l t s ) ; It corresponds to Figure 7.4. Kommenter: kanaler. Typical is the big reception-loop. deklarasjon inkludert tabell ( array ) for svar-kanaler. Note that there is only one receive-channel. rollen til indeksen: each process gives it s own identity, so to say. bruk av meta-notasjon for argumenter (??) The client-server example is simplified insofar, as there is only one operation, called request. What would happen if one had more than one? That would be Fig. 7.5 (not shown). The solution is simple: one could add the message class as additional argument and the client would then need a case construct inside the loop. Since that is such a useful pattern, one could introduce such a facility directly in a (concurrent) programming language. Does someone knows such a feature? In some sense, objects are like this (even if not necessarily there is concurrency). What s the disadvantage of the above sketched encoding of support of many kinds of requests? Typing. The above process can be seen as a process realization (MP) of a simple monitor. The simplifications are, only 1 procedure (but we sketched how to generalize), and the absence of condition variables. The latter phenomenon will be introduced via an example (resource manager) and then generalized. But first a recap of monitors.

30 Monitor realisert vha. meldingsutveksling Klassisk monitor: Kontrollert adgang til en ressurs Permanente variable (mon.var.) ivaretar ressurs-tilstand Adgang til ressursen via prosedyrer Prosedyrene utføres med gjensidige utelukkelse Betingelsesvariable for synkronisering (eng.: cond. var.s) Kan også realisere en monitor vha. en tjener-prosess og meldingsutveksling. Kalles en aktiv monitor i boka: aktive prosess (løkke), isf. passive prosedyrer. Martin Steffen (UiO) / 31

31 Examples Monitor realisert vha. meldingsutveksling Monitor realisert vha. meldingsutveksling Klassisk monitor: Kontrollert adgang til en ressurs Permanente variable (mon.var.) ivaretar ressurs-tilstand Adgang til ressursen via prosedyrer Prosedyrene utføres med gjensidige utelukkelse Betingelsesvariable for synkronisering (eng.: cond. var.s) Kan også realisere en monitor vha. en tjener-prosess og meldingsutveksling. Kalles en aktiv monitor i boka: aktive prosess (løkke), isf. passive prosedyrer. Next the book explains how one can realize a monitor with MP. It does so by first looking at an example. The position/role of monitors here (in the section C/S), is not completely clear. (ivareta: maintain, løkke = loop)

32 Eksempel: allokator for flerenhetsressurs Flerenhetsressurs: ressurs som består av flere identiske deler. Eksempler: minneblokker, filblokker. Brukere (klienter) får tildelt enheter, bruker dem, og gir dem tilbake til allokatoren (frigir enheter). Forenkling: brukere får og frigir én og én ressurs. Lager to versjoner: monitor tjener- og klient-prosesser, meldingsutveksling Martin Steffen (UiO) / 31

33 Examples Eksempel: allokator for flerenhetsressurs Eksempel: allokator for flerenhetsressurs Flerenhetsressurs: ressurs som består av flere identiske deler. Eksempler: minneblokker, filblokker. Brukere (klienter) får tildelt enheter, bruker dem, og gir dem tilbake til allokatoren (frigir enheter). Forenkling: brukere får og frigir én og én ressurs. Lager to versjoner: monitor tjener- og klient-prosesser, meldingsutveksling Brukere (klienter) må følge protokollen. Én og én : forenkling.

34 Om allokatoren som monitor Bruker passing the condition forenkler senere oversetting til tjener-prosess. Uallokerte (frie) enheter representeres som mengde, Type set, med operasjoner insert og delete. Martin Steffen (UiO) / 31

35 Semafor med passing the condition monitor FIFOSemaphore { i nt s = 0; ## s >= 0 cond pos ; procedure P() { i f ( s == 0) wait ( pos ) ; e l s e s = s 1; procedure V() { i f ( empty ( pos )) s = s + 1; e l s e s i g n a l ( pos ) ; (fig. 5.3 i Andrews) Martin Steffen (UiO) / 31

36 Examples Semafor med passing the condition Semafor med passing the condition monitor FIFOSemaphore { i n t s = 0; ## s >= 0 cond pos ; procedure P() { i f ( s == 0) wait ( pos ) ; e l s e s = s 1; procedure V() { if (empty ( pos )) s = s + 1; e l s e s i g n a l ( pos ) ; (fig. 5.3 i Andrews) Meta: forstå passing the condition slik at det ikke blir rot på forlesning igjen.... The code is given/repeated here as illustration for the rec. allocator (which basically is the same). The only addition will be the manipulation of of the data-structure containing the resources and the arguments of the procedures, again used for the resources. The monitor here is the example for passing the condition. Basically, the p-t-c here is used since monitor, in some sense, has less power than a counting semapho

37 Allokatoren som monitor monitor Resource Allocator { i nt a v a i l = MAXUNITS; set units =... # i n i t i e l l e v e r d i e r ; cond fr ee ; # sign. \ naar prosess oensker enhet procedure acquire ( i nt &id ) { i f ( a v a i l == 0) wait ( f r ee ) ; e l s e a v a i l = avail 1; remove ( units, id ) ; procedure r e l ea s e ( i nt id ) { i n s e r t ( units, id ) ; i f ( empty ( f r e e )) a v a i l = a v a i l +1; e l s e s i g n a l ( fr ee ) ; (fig. 7.6 i Andrews) # var. parameter # passing the condition Martin Steffen (UiO) / 31

38 Examples Allokatoren som monitor Allokatoren som monitor monitor Resource Allocator { int avail = MAXUNITS; set units =... # i n i t i e l l e v e r d i e r ; cond free ; # sign. \ naar prosess oensker enhet procedure acquire ( int &id ) { # var. parameter if ( avail == 0) wait ( fr ee ) ; e l s e avail = avail 1; remove ( units, id ) ; procedure release ( int id ) { insert ( units, id ) ; i f (empty ( fr ee )) avail = avail +1; e l s e signal ( free ) ; # passing the condition (fig. 7.6 i Andrews) Kommenter: kommentarene (sic)! The monitor has two procedures. The shared, protected resource is units (and avail) and accessed by the internal manipulation procedures remove and insert. The cond. variable is free. The monitor is rather unspectacular. Actually, it is very close ti the monitor implementation of a bounded buffer (p. 214) buffer (using signal and continue). The bounded buffer there uses 2 condition variables (and additionally uses a while-loop instead of if). The reason why one of the cond-variables ()... Even more resemblance is resemblance to Fig. 5.3, p. 211, just shown. The set units contains a set of things, initially full (MAXUNITS). avail {0,... maxints. Avail counts the number of units in the set. The operation empty(free) is an operation on the condition variables (p. 211). It can check the number of processes on the wait-queue of a cond. var.

39 Om allokatoren som tjener-prosess Allokatoren har to typer operasjoner: få enhet, frigi enhet må kodes inn i argumentene ved forespørsel (request). Bruker nøstet if-setning (2 nivåer): sjekker først type operasjon, så tilsvarende som monitor-if. Kan ikke vente (wait(free)) når ingen enheter er ledige. Må lagre forespørselen og komme tilbake til den senere kø av utestående forespørsler (queue; insert, remove). Kanal-deklarasjoner: type op kind = enum(acquire, RELEASE ) ; chan request ( i nt clientid, op kind kind, i n t unitid ) ; chan r eply [ n ]( i n t unitid ) ; Martin Steffen (UiO) / 31

40 Examples Om allokatoren som tjener-prosess Om allokatoren som tjener-prosess Allokatoren har to typer operasjoner: få enhet, frigi enhet må kodes inn i argumentene ved forespørsel (request). Bruker nøstet if-setning (2 nivåer): sjekker først type operasjon, så tilsvarende som monitor-if. Kan ikke vente (wait(free)) når ingen enheter er ledige. Må lagre forespørselen og komme tilbake til den senere kø av utestående forespørsler (queue; insert, remove). Kanal-deklarasjoner: type op kind = enum(acquire, RELEASE ) ; chan request ( int clientid, op kind kind, int unitid ) ; chan reply [ n ] ( i nt unitid ) ; Kommenter typedeklarasjon vha. type. Tegn sekvensdiagram: acquire!, unitid?, RELEASE! The sequence diagram shows the scenario interaction of a client with the server It is all a bit cumbersom. Anyway, the acquire consists of two way communication, the release of a one-way.

41 Allokator: klient-prosesser process C l ient [ i = 0 to n 1] { i nt unitid ; send request ( i, ACQUIRE, 0) # gjoer f o r e s p o e r s e l r e ceive r eply [ i ] ( unitid ) ;... # bruk r essursen unitid send request ( i, RELEASE, unitid ) ; # f r i g j o e r ressursen... (fig. 7.7(b) i Andrews) Martin Steffen (UiO) / 31

42 Examples Allokator: klient-prosesser Allokator: klient-prosesser process C l ient [ i = 0 to n 1] { int unitid ; send request ( i, ACQUIRE, 0) # gjoer forespoersel r eceive r eply [ i ] ( unitid ) ;... # bruk r essursen unitid send request ( i, RELEASE, unitid ) ; # frigjoer ressursen... (fig. 7.7(b) i Andrews) TODO: kommenter at i ikke trengs ved RELEASE. Komment deklarasjon av tabell av prosesser. Forklar argumentene til request og hvorfor det siste ikke brukes ved ACQUIRE. At the example we see also the problems of this encoding (of using one request-channel for multiple messages (here 2)). As said, a server is a process that repeatedly serves request from clients a big outer while loop (the server loop). The next one is also generally typical for the encoding of a monitor as processe: the dispatch (a case match, here pretty stupidly done, with an else-catch-all), here a case distrinction on 2 message types

43 Allokator: tjener-prosess process Resource Allocator { i nt a v a i l = MAXUNITS; set units =... # i n i t i e l l verdi queue pending ; # i n i t i e l t tom i nt clientid, unitid ; op kind kind ;... while ( true ) { r eceive request ( clientid, kind, unitid ) ; i f ( kind == ACQUIRE) { i f ( a v a i l == 0) # husk f o r e s p o e r s e l i n s e r t ( pending, c l i e ntid ) ; el s e { # utfoer f o r e s p o e r s e l naa avail ; remove ( units, unitid ) ; send r eply [ c l i e ntid ] ( unitid ) ; e l s e { # kind == RELEASE i f empty ( pending ) { # r eturner t i l units a v a i l ++; i n s e r t ( units, unitid ) ; e l s e { # a l l o k e r t i l ventende k l i e n t remove ( pending, c l i entid ) ; send r eply [ c l i e ntid ] ( unitid ) ; # f i g. \ 7.7 i Andrews ( omskrevet ) Martin Steffen (UiO) / 31

44 Examples Allokator: tjener-prosess Allokator: tjener-prosess process Resource Allocator { int avail = MAXUNITS; set units =... # i n i t i e l l verdi queue pending ; # i ni ti e lt tom int clientid, unitid ; op kind kind ;... while ( true ) { receive request ( clientid, kind, unitid ) ; if ( kind == ACQUIRE) { if ( avail == 0) # husk forespoersel insert ( pending, clientid ) ; e l s e { # utfoer f o r e s p o e r s e l naa avail ; remove ( units, unitid ) ; send reply [ clientid ] ( unitid ) ; else { # kind == RELEASE if empty ( pending ) { # returner t il units avail++; insert ( units, unitid ) ; else { # alloker ti l ventende klient remove ( pending, clie n tid ) ; send reply [ clientid ] ( unitid ) ; # f i g. \ 7.7 i Andrews ( omskrevet ) Kommenter variabel pending. Hva skjer etter insert sammenlign med monitor. Byttet om første indre if-setning for å ligne mer på monitor-versjonen. Andrews versjon: Meta: parenteser rundt empty(pending) er heller ikke i boka, sjekk trykkfeillista. The outer while loop and the dispatch are pretty obvious how to encode. The trick part is the scheduling (i.e., the waiting when the resource is not there... ). Abstractly it is clear that especially one data structure is missing in such a process which a monitor offers for free: the queue and the concerning operations/scheduling related to it. Hence, we must implement it ourselves. The code here differs from the version in Andrews. In the changed version, there is a better match with the monitor implementation (using passing-the-condition) anyway. The wait is directly implemented by inserting into the queue. Here, of course, we need to explicity add the identity into the queue, where the the identity of the activity/thread is handled of course automatically for monitors in the run-time system. For the release, we can simply replace the emptyness-check on the condition variable by an empty-ness check on the self-programmed queue, give back the resources to the set. Note the reply here! Let s analyse the ACQUIRE-part. It seems that unitid is not used, really. First assume, in the easy case, that a client tries to aquire a unit and that there enough units there. In this case, avail is counted down (till it reaches 0), the unit is removed from the pool, and the correct client (identified by its id), gets the resource as reply. That the reply is send corresponds to the fact that the monitor-procedure returns. More interesting is when there is no resource availabe (= avail = 0. In this case the request cannot be served, more precisely, it cannot be served now. That means two things: First, they must be no reply now, and secondly, it must be remembered that the process has issued such a request, and hence it is put on the pending queue, using it s identity. Note that the unitid is not remembered. Note the protocol at the client side, which is a sequence.

45 Examples Allokator: tjener-prosess Allokator: tjener-prosess process Resource Allocator { int avail = MAXUNITS; set units =... # i n i t i e l l verdi queue pending ; # i ni ti e lt tom int clientid, unitid ; op kind kind ;... while ( true ) { receive request ( clientid, kind, unitid ) ; if ( kind == ACQUIRE) { if ( avail == 0) # husk forespoersel insert ( pending, clientid ) ; e l s e { # utfoer f o r e s p o e r s e l naa avail ; remove ( units, unitid ) ; send reply [ clientid ] ( unitid ) ; else { # kind == RELEASE if empty ( pending ) { # returner t il units avail++; insert ( units, unitid ) ; else { # alloker ti l ventende klient remove ( pending, clie n tid ) ; send reply [ clientid ] ( unitid ) ; # f i g. \ 7.7 i Andrews ( omskrevet ) In the monitor setting, these sequencing is the semantics of a blocking call. Now, what about RELEASE. That s a bit problematic, as here the code differs from the one in the monitor, but let s stick to the code. The simple case is, when no one is in the pending queue. In this case, the counter goes one (one is free again, it says), and the resource is added to the pool. More tricky is the part, when there is signaling, i.e., when the pending-queue is non-empty. Now, this means, the process at the head of the list is still waiting for his reply, and basically that s what we are sending him, after removing the entry from the pending queue (with remove ). Here is the difference to the monitor implementation. The difference does not only concerns the method RELEASE here but also the ACQUIRE. In the monitor-approach, the two dual operations remove and insert on the resource pool are unconditional. Note that remove and insert are also used on the pending/waiting queue. The difference is not crucial

46 i f ( kind == ACQUIRE) { i f ( a v a i l > 0) { # utfoer f o r e s p o e r s e l naa avail ; remove ( units, unitid ) ; send r eply [ clientid ] ( unitid ) ; e l s e # husk f o r e s p o e r s e l i n s e r t ( pending, c l i entid ) ; e l s e { # kind == RELEASE Martin Steffen (UiO) / 31

47 if ( kind == ACQUIRE) { Examples i f ( a v a i l > 0) { # utfoer f o r e s p o e r s e l naa avail ; remove ( units, unitid ) ; send r eply [ c l i e ntid ] ( unitid ) ; e l s e # husk f o r e s p o e r s e l insert ( pending, clientid ) ; else { # kind == RELEASE What it wrong with Andrew s code?

48 Dualitet: monitorer, meldingsutveksling monitor-baserte programmer meldingsbaserte programmer permanente variable lokale tjener-variable prosedyre-identifikatorer request-kanal, operasjonstyper prosedyrekall send request(), receive reply[i]() gå inn i monitor receive request() prosedyre- retur send reply[i]() wait-setning lagre utestående forespørsel i kø signal-setning hent og prosessér utest. forespørsel (reply) prosedyrekropp forgreninger i if-setn. ihht. op.-type Martin Steffen (UiO) / 31

49 Examples Dualitet: monitorer, meldingsutveksling Dualitet: monitorer, meldingsutveksling monitor-baserte programmer meldingsbaserte programmer permanente variable lokale tjener-variable prosedyre-identifikatorer request-kanal, operasjonstyper prosedyrekall send request(), receive reply[i]() gå inn i monitor receive request() prosedyre- retur send reply[i]() wait-setning lagre utestående forespørsel i kø signal-setning hent og prosessér utest. forespørsel (reply) prosedyrekropp forgreninger i if-setn. ihht. op.-type (Hopp over?) Permanente variable betyr monitor-variable. This slide is a summary of the principles shown in the example. forgrening = branching/forking, ihht. = wrt.

50 Synkron meldingsutveksling Primitiver: Nytt primitiv for sending: synch send c(expr 1,...,expr n ); Blokkerende : sender venter til melding er mottatt på kanal, dvs. sender og mottaker synkroniser utsendelse og mottak av melding. Ellers som asynkron meld.utv.: receive c(var 1,...,var n ); empty(c); Martin Steffen (UiO) / 31

51 Examples Synkron meldingsutveksling Synkron meldingsutveksling Primitiver: Nytt primitiv for sending: synch send c(expr1,...,exprn); Blokkerende : sender venter til melding er mottatt på kanal, dvs. sender og mottaker synkroniser utsendelse og mottak av melding. Ellers som asynkron meld.utv.: receive c(var1,...,varn); empty(c); Til sammenligning er asynkron sending ikke-blokkerende.

52 Synkron meldingsutveksling: diskusjon Fordeler: Gir maksimal- størrelse på kanal (buffer i impl.) hvis antall prosesser er begrenset. Sender synkroniserer med mottaker mottaker har maks. 1 utestående melding per kanal per sender sender har maks. 1 usendt melding Ulemper: Redusert parallellitet : når 2 prosesser kommuniserer er alltid 1 blokkert. Større fare for vranglås (eng. deadlock). Martin Steffen (UiO) / 31

53 Examples Synkron meldingsutveksling: diskusjon Synkron meldingsutveksling: diskusjon Fordeler: Gir maksimal- størrelse på kanal (buffer i impl.) hvis antall prosesser er begrenset. Sender synkroniserer med mottaker mottaker har maks. 1 utestående melding per kanal per sender sender har maks. 1 usendt melding Ulemper: Redusert parallellitet : når 2 prosesser kommuniserer er alltid 1 blokkert. Større fare for vranglås (eng. deadlock). Sender: maks. 1 utestående melding uavhengig av antall kanaler Eksempel: allokatoren, klient som frigir ressurs venting unødvendig

54 Eksempel: blokkering ved synkron meldingsutveksling chan values ( i nt ) ; process Producer { i nt data [ n ] ; for [ i = 0 to n 1] {... # beregning... ; synch send values ( data [ i ] ) ; process Consumer { i nt r e s u l t s [ n ] ; for [ i = 0 to n 1] { r eceive values ( r e s u l t s [ i ] ) ;... # beregning... ; Martin Steffen (UiO) / 31

55 Eksempel: blokkering ved synkron meldingsutveksling chan values ( i nt ) ; process Producer { i nt data [ n ] ; for [ i = 0 to n 1] {... # beregning... ; synch send values ( data [ i ] ) ; process Consumer { i nt r e s u l t s [ n ] ; for [ i = 0 to n 1] { r eceive values ( r e s u l t s [ i ] ) ;... # beregning... ; Anta både produsent og konsument varierer i tidsbruk. Kommunikasjonen ved synch send/receive vil blokkere. Med asynkron meldingsutveksling reduseres ventingen. Martin Steffen (UiO) / 31

56 Examples Eksempel: blokkering ved synkron meldingsutveksling Eksempel: blokkering ved synkron meldingsutveksling chan values ( int ) ; Anta både produsent og process Producer { i n t data [ n ] ; konsument varierer i tidsbruk. for [ i = 0 to n 1] { Kommunikasjonen ved... # beregning... ; synch send values ( data [ i ] ) ; synch send/receive vil blokkere. process Consumer { int results [n ] ; Med asynkron for [ i = 0 to n 1] { meldingsutveksling reduseres r eceive values ( r e s u l t s [ i ] ) ;... # beregning... ; ventingen. Produsent: lager n heltall Konsument: leser tallene Asynkron meld.utv.: kun venting når produksjonen er for lav The word blocking is maybe misleading here. The program does not block as such (in the sense of deadlock, it is just that that spead of the two processes is limited by the slower one. So the buffer/asynchronous channel decouples the speed of the two participants, which is exactly what a buffer is intended for. This works well, in case the average speed of both is the same, but there are some burst and ups and downs In case one of the two is consistently slower, the decoupling of course does not help. For those cases we have the mechanims to avoid busy way, of course.

57 Eksempel: chan in1 ( i nt ), in2 ( i n t ) ; process P1 { i nt v1 = 1, v2 ; synch send in2 ( v1 ) ; r e ceive in1 ( v2 ) ; process P2 { i nt v1, v2 = 2; synch send in1 ( v2 ) ; r e ceive in2 ( v1 ) ; Martin Steffen (UiO) / 31

58 Eksempel: vranglås ved synkron meldingsutveksling chan in1 ( i nt ), in2 ( i n t ) ; process P1 { i nt v1 = 1, v2 ; synch send in2 ( v1 ) ; r e ceive in1 ( v2 ) ; process P2 { i nt v1, v2 = 2; synch send in1 ( v2 ) ; r e ceive in2 ( v1 ) ; P1 og P2 blokker på synch send vranglås. Én prosess må endres til å gjøre receive først asymmetrisk løsning. Martin Steffen (UiO) / 31

59 Eksempel: vranglås ved synkron meldingsutveksling chan in1 ( i nt ), in2 ( i n t ) ; process P1 { i nt v1 = 1, v2 ; synch send in2 ( v1 ) ; r e ceive in1 ( v2 ) ; process P2 { i nt v1, v2 = 2; synch send in1 ( v2 ) ; r e ceive in2 ( v1 ) ; P1 og P2 blokker på synch send vranglås. Én prosess må endres til å gjøre receive først asymmetrisk løsning. Med asynkron meldingsutveksling (send) går alt bra. Martin Steffen (UiO) / 31

60 Examples Eksempel: Eksempel: vranglås ved synkron meldingsutveksling chan in1 ( i nt ), in2 ( i n t ) ; P1 og P2 blokker på synch send process P1 { vranglås. i n t v1 = 1, v2 ; synch send in2 ( v1 ) ; Én prosess må endres til å gjøre receive in1 ( v2 ) ; receive først asymmetrisk løsning. process P2 { i n t v1, v2 = 2; Med asynkron synch send in1 ( v2 ) ; meldingsutveksling (send) går alt receive in2 ( v1 ) ; bra. Både P1 og P2 vil sende først! Vranglås mindre problem for applikasjoner der sending og mottak går parvis, typisk produsent/konsument og klient/tjener.

61 Sammenheng mellom programmeringsmekanismer busy waiting videreutvikling implisitt eksklusjon semaforer dataverdier monitorer meldingutv. RPC / rendezvous Martin Steffen (UiO) / 31

62 Examples Sammenheng mellom programmeringsmekanismer Sammenheng mellom programmeringsmekanismer busy waiting videreutvikling implisitt semaforer eksklusjon dataverdier monitorer meldingutv. RPC / rendezvous Kan flyttes til siste forelesning før RPC og rendezvous. TODO: en engelsk-forelesning i 2005 sluttet 15 min før tiden.

63 References I [1] G. R. Andrews. Foundations of Multithreaded, Parallel, and Distributed Programming. Addison-Wesley, Martin Steffen (UiO) / 31