LaSa

lle

On

Lin

e

EN

GIN

YER

IES

MODELAT I VERIFICACI DE SISTEMES DISTRIBUTS

Guia destudi Miquel Beltran

2010 Creative Commons Deed

Creative Commons License Deed Reconeixement-No comercial-Sense obres derivades 3.0 Espanya

Vost s lliure de: Copiar, distribuir i comunicar pblicament lobra.

Sota els segents condicionants:

Reconeixement.

Sha de referenciar aquesta obra a Miquel Beltran - Enginyeria La Salle (Semipresencial)

No comercial. No es pot utilitzar aquesta obra per a finalitats comercials.

Sense obres derivades.

No es pot alterar, transformar o generar una obra derivada a partir daquesta.

Quan reutilitzeu o distribuu l'obra, heu de deixar ben clar els termes de la llicncia de l'obra.

Alguna d'aquestes condicions pot no aplicar-se si obteniu el perms del titular dels drets d'autor.

No hi ha res en aquesta llicncia que menyscabi o restringeixi els

drets morals de l'autor.

Els drets derivats d'usos legtims o altres limitacions reconegudes

per llei no queden afectats per l'anterior

Aix s un resum fcilment llegible del text legal (la llicncia completa) disponible en els idiomes segents:

Catal Castell Basc Gallec

Crdits

Autor: Miquel Beltran

Editor: Llus Vicent

Coordinaci lingstica: Sara Laso

Revisi lingstica: Carmina Mateo

Maquetaci: Vctor Ballesteros

Disseny de portada: Vctor Ballesteros

Aquesta edici ha comptat amb el suport de lAgncia de Gesti dAjuts Universitaris i de Recerca (AGAUR) de la Generalitat de

Catalunya en la Convocatria dajuts a ledici i la difusi de llibres de text o manuals universitaris i llibres cientificotcnics, en suport

paper o en suport electrnic, escrits en llengua catalana (DILL 2010)

ISBN: 978-84-937712-9-4

Modelat i verificaci de sistemesdistributs

Una introducci

Miquel Bertran

Reconeixement i agrament

El format daquests apunts no hagus estat possible sense el tre-ball sistemtic de Roman Duch i la collaboraci de Francesc-XavierBabot. El model de xarxa de comunicaci descrit en la part finalva sorgir del treball amb August Climent, Joan Navarro i Francesc-Xavier Babot. El dileg regular amb Xavi Canaleta s molt apreciat.

La notaci de modelat ha servit en docncia, recerca i projectes pera la indstria; grcies a la collaboraci de moltes persones en lacreaci de diversos entorns de desenvolupament. Recentment i desdel principi: Albert Duran i Miquel Porta. Ms recentment: Francesc-Xavier Babot, Joan-Andreu Margalef i Carles Blanc. En els temps decreaci de la notaci i dels primers entorns: Jordi Forga, FrancescOller, Felipe lvarez-Cuevas, Joan Viaplana, Josep M. Solanas, Josep-Artur Frau, Joan-Manuel Espejo i Toni Ripoll. No em voldria oblidar dening. Excuses si ho faig. A tots ells estenc el meu reconeixement iagrament ms profund.

NDEX

1 Introducci 11.1 Objectius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Modelat i verificaci en el desenvolupament de sistemes . . . . . 21.3 Resum i continuaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Modelat de sistemes prpiament distributs 72.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Procediments modulars . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Parallelisme i comunicaci . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Sistemes amb memria compartida 333.1 Motivaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Suposicions de base i validaci de models . . . . . . . . . . . . . . . 343.3 Propietats dun model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4 La mquina de transicions finites (MTF) dun model . . . . . . . . 483.5 Formulaci de propietats dun model . . . . . . . . . . . . . . . . . . 523.6 Demostraci de propietats dun model . . . . . . . . . . . . . . . . . 543.7 Extensi a sistemes prpiament distributs . . . . . . . . . . . . . . 583.8 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.9 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 Exemples sobre lexclusi mtua (EM) 694.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Esquema i propietats desitjables de les solucions a lEM . . . . . 694.3 Intents i solucions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.4 Soluci basada en una instrucci especial . . . . . . . . . . . . . . . 844.5 Verificaci amb refor de linvariant . . . . . . . . . . . . . . . . . . . 884.6 EM prpiament distribuda . . . . . . . . . . . . . . . . . . . . . . . . . 904.7 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.8 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5 Modelat i verificaci amb semfors 995.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.2 Elements i propietats bsiques . . . . . . . . . . . . . . . . . . . . . . 1005.3 Exemple: exclusi mtua amb semfors . . . . . . . . . . . . . . . . 1035.4 Exemple: cua de comunicaci amb semfors . . . . . . . . . . . . . 1085.5 Implementaci i avaluaci . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.6 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.7 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

i

6 Modelat i verificaci amb monitors 1236.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.2 Trets caracterstics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246.3 Operacions invocades a cada part dun monitor . . . . . . . . . . . 1256.4 Exemple: monitor de cua . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.5 Funcionament dun monitor . . . . . . . . . . . . . . . . . . . . . . . . . 1336.6 Verificaci de models amb monitors . . . . . . . . . . . . . . . . . . . 1366.7 Exemple. El monitor daccs a una taula . . . . . . . . . . . . . . . . 1436.8 Monitors amb signals a llocs arbitraris . . . . . . . . . . . . . . . . . 1506.9 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.10Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

7 Elements per a la realitzaci de monitors 1657.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657.2 Monitors realitzats amb semfors . . . . . . . . . . . . . . . . . . . . 1657.3 Organitzaci de sistemes operatius amb monitors . . . . . . . . . 1687.4 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787.5 Problemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Bibliografia 181

A Programaci seqencial en PADD 183A.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183A.2 Procediments modulars . . . . . . . . . . . . . . . . . . . . . . . . . . . 183A.3 Sentncies per definir la part algorsmica . . . . . . . . . . . . . . . 186A.4 Definici de tipus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189A.5 El mdul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190A.6 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

B Un model de xarxa de comunicaci 193B.1 Introducci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193B.2 Marc daplicaci del model . . . . . . . . . . . . . . . . . . . . . . . . . 193B.3 Els nodes client de la xarxa . . . . . . . . . . . . . . . . . . . . . . . . . 194B.4 Requeriments del model de la xarxa . . . . . . . . . . . . . . . . . . . 195B.5 Disseny del model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195B.6 El mdul que cont el model de la xarxa . . . . . . . . . . . . . . . . 197B.7 La xarxa prpia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198B.8 Entrada a la xarxa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199B.9 Sortida de la xarxa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200B.10El parallelisme global . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

ii

1 Introducci

1.1 Objectius

Avui, pujar la velocitat dels processadors ja no s possible augmentant la freqn-cia del rellotge, a causa de les limitacions fsiques dels materials electrnics. Percontinuar pujant la velocitat de clcul, els fabricants fan treballar en paral.lel unsquants processadors, dins el mateix xip. Daquests xips en diuen multicores. Lavelocitat saugmenta amb el paral.lelisme i la comunicaci entre els cores, pro-cessadors connectats en paral.lel. No obstant, la programaci es complica. Elparallelisme i la comunicaci poden entrar en la programaci, que fins ara eraseqencial.

El treball en paral.lel de processadors tamb es t en les xarxes de comuni-caci. Els seus nodes dialoguen amb protocols de comunicaci. Tamb surten sistemes multitasca, mono i multiprocessador, els quals corren sobre els sis-temes operatius actuals. Encara que en monoprocessadors no hi ha paral.lelismeprpiament, el seu funcionament es pot modelar amb paral.lelisme i comunica-cions. Finalment, lelectrnica digital tamb pot ser vista, en sentit ampli, comel treball en paral.lel de les diverses parts daquesta electrnica.

En aquests apunts un sistema distribut s tot sistema real que pot ser mo-delat, de forma natural (propera al sistema), amb processos parallels, operacionsde comunicaci entre ells i memria compartida entre tots o alguns dells. Un casparticular de sistema distribut s el que es modela de forma natural amb proces-sos parallels comunicants solament. Sanomena, en aquests apunts, sistemaprpiament distribut. En ell, els processos no comparteixen memria.

Els sistemes que shan esmentat al principi sn exemples de sistema distribut. Engeneral, ho s tot sistema real que t fsicament ms dun processador comunicant-se via memria compartida o via operacions de comunicaci.

La paraula concurrent o b concurrncia est molt relacionada. Es refereix asistemes en que tasques daplicaci comparteixen memria. El cas monoproces-sador, aix com els sistemes operatius monoprocessador, van ser els primers sis-temes reals que van motivar la recerca sobre sistemes concurrents; la referncia[9] en dna una perspectiva. Amb els multiprocessadors davui, la concurrn-cia sha ests i aplicat a ells. Aquesta extensi es pot anomenar concurrncia idistribuci. La noci de sistema distribut, en aquests apunts, ns equivalent.

Les notacions de modelat amb paral.lelisme explcit i operacions de comunicacisn idnies per expressar totes les aplicacions anteriors. Hi ha moltes notacionsamb aquestes caracterstiques: PROMELA, del verificador SPIN [12], ADA [6, 19],SPL, dels llibres de Manna i Pnueli [16, 17], OCCAM [13, 14, 15]. Aqu susar unanotaci de modelat que, a ms dels elements que tenen les notacions esmen-tades, disposa de variables compartides, semfors i monitors. Daquesta formasaconsegueix un equilibri entre comunicaci prpia i comunicaci per memriacompartida. En aquesta lnia, els apunts tenen els objectius segents:

1

Introduir elmodelat de sistemes distributs en una notaci amb paral.lelismeexplcit, pas de missatges, semfors i monitors.

Introduir la verificaci de sistemes distributs. Saprendr a pensar ambrigor sobre aquests sistemes; en altres paraules: a formular les seves pro-pietats i a verificar-les amb mtodes matemtics.

1.2 Modelat i verificaci en el desenvolupamentde sistemes

Requeriments

Especificaci derequerimients

Disseny

Especificaci dedisseny

Modelat

Verificaci Model Simulaci

Mapeig

VHDL . . . Programa en C . . . Programa en C

Testeig

{Sistemareal }

Figura 1.1.: Desenvolupament basat en modelat, simulaci i verificaci

Modelar s til, no solament en el disseny de computadors, sino tamb en eldesenvolupament de sistemes en general, tan hardware com software. Per

2

exemple, el disseny delectrnica en la qual intervenen processadors program-ables, el disseny de programes sobre sistemes multiprocessador o sobre com-putadors multiprocessador. Totes aquestes situacions poden ser freqents en unavida professional.

En lestudi dels apunts shan de tenir sempre presents dos nivells o plans per atot sistema distribut.

1. El model, o els models del sistema.

2. La descripci detallada del sistema real. Feta en C, en VHDL, amb esquemes,etc.

Es treballar en el primer nivell, en el qual sha de pensar duna forma ms abs-tracte que en el segon. En un sol cas es mostra el nivell real, el format perinstruccions mquina corrent sobre multiprocessadors. Les paraules tasca dapli-caci, thread, processador, etc ... sempre es refereixen a sistemes reals. Laparaula procs sempre es refereix al nivell abstracte o del model.

Construir un model s lequivalent a fer una maqueta dun edifici. El model cor-respon a una simplificaci de la realitat, per ajuda a analitzar-la tot simulant elcomportament del model o simplement raonant sobre les propietats que posseeix(calcula el que volem?, es "penja"?, etc.). Aix ltim sanomena vericar les pro-pietats del model. La simulaci consisteix a fer crrer el model en un simulador,aix un pot fer-se una idea del funcionament, molt abans de tenir el sistema re-al. Permet corregir el disseny en les primeres fases del desenvolupament. Laverificaci es fa amb lajut dels vericadors, eines que analitzen el model sensefer-lo crrer. Simulaci i verificaci sn fonamentals per obtenir dissenys segurs ifiables.

Lesquema de la figura 1.1. dna una visi simplificada del procs de desenvolu-pament basat en modelat, simulaci i verificaci. En ell tenim activitats i resul-tats daquestes activitats. Els resultats poden ser simplement documents o bprogrames, diagrames de blocs, etc... Finalment, hi ha el sistema real descriten VHDL, amb esquemtics, o una altra forma en el cas delectrnica dedicada.En C o similars en el cas de programes sobre multiprocessadors. Descrits de lesdues maneres segons les parts dun sistema composat per electrnica dedicada iprocessadors.

Per donar una visi sobre el paper i situaci del modelat, simulaci i verificaci enel procs de desenvolupament dun sistema digital, representat a la figura 1.1., acontinuaci sen dna una descripci de les fases:

Requeriments Formulaci de qu ha de fer el sistema. Han destar-hi da-cord els clients i els constructors de larquitectura. Els clients poden ser undepartament de la mateixa empresa. El seu resultat s el document especi-caci dels requeriments. Alguns dels requeriments poden expressar-se enfrmules lgiques, les quals corresponen a propietats concretes. Llavors esdir que les propietats estan expressades formalment. Existeixen molteslgiques per formular propietats. Exemples: la lgica de primer ordre o cl-cul de predicats, les lgiques temporals, la notaci matemtica Z, etc...

Disseny Concepci de com el sistema realitzar els requeriments, contingutsen el document de requeriments. Cal escollir tecnologies, estructures, com-ponents existents per a ser usats, etc., relacions entre les parts i compo-nents del sistema, etc... El seu resultat s el document despecicaci deldiseny. Durant aquesta fase pot fer-se necessria la revisi i posada al dia

3

del document de requeriments, a causa del major grau de concreci quansha realitzat el disseny.

Modelat Concepci duna maqueta del futur sistema, segons el disseny ante-riorment dut a terme. Existeixen llenguatges de modelat, els quals han deser senzills, esquemtics i han de poder ser aplicats tan al hardware com alsoftware. El resultat del modelat s el model o els models, ja que en ms du-na situaci s convenient modelar diferents aspectes del sistema en modelsdiferents. El model ha de poder crrer sobre un simulador.

Verificaci del model. Les propietats expressades formalment sn objecte decontrast amb el model. Un estil freqent de raonament que sintrodur sel de la demostraci matemtica basada en sistemes de transicions finites,a partir del captol 3. Aquest treball es fa sobre vericadors, eines softwaredajut a la verificaci. Per usar-les cal saber la cultura tcnica que es treballaals apunts.

Simulaci Es tracta de fer crrer el model a fi dobtenir traces de la seva exe-cuci i veure si el comportament s lesperat. En realitat, el model va inseriten un banc de proves, sobre el qual shan preparat casos de prova. La si-mulaci i proves sn complementries amb la verificaci. Les dues ajudena descobrir errors abans dentrar en els detalls del sistema real. Com a re-sultat de la simulaci, i/o de la verificaci, pot ser necessari tornar enrere imodificar el disseny.

Mapejat Aquesta activitat obt el sistema real partint del model. Es com unatraducci i ampliaci, la qual ha de respectar lestructura del model a fi queconservi les propietats que shan comprovat en les fases danlisi i de simula-ci. Per tant, sha de seguir una sistemtica de mapejat. En molts escenaris,existeixen eines que obtenen la codificaci en C, partint del model i de ladefinici de quins processadors han de crrer les diferentes parts del model.

Testeig Es refereix a les proves de tot tipus que han de fer-se sobre el sistemareal. Aqu no sentra en detall. Tan sols cal dir que les fases de modelat,verificaci i simulaci fan que el testeig pugui ser molt ms curt.

A la figura 1.2., la corba creixent indica el cost de detectar i corregir un erroro un mal plantejament dun sistema, en moments diversos del procs de desen-volupament. Ho indica en funci del moment (temps) en el que succeeix aix.Aquest moment pot ser molt aviat, quan solament shan pensat i fet documents;o b molt tard, quan ja sest validant el sistema davant els usuaris. Com es potveure, per al mateix error, el cost de corregir-lo s molt ms elevat quansest molt ms endavant en el desenvolupament.

La corba decreixent de la figura 1.2. quantifica el nombre de decisions a prendredurant el desenvolupament; decisions correctes, naturalment. Sobserva que lesdecisions de disseny han de tenir lloc durant les fases inicials, anomenades tambfases abstractes. A les fases finals serien molt costoses, ja que correspondrien acanvis. Les fases finals es dediquen a realitzar les bones decisions preses durantles inicials.

s degut a aquest fet que la construcci de models, juntament ambllur verificaci i simulaci, disminueixen els costos de desenvolupament,

4

COST DE CORRECCI DERRORS

Costos elevats

NOMBRE DE DECISIONS

CORRECTES

0INICI DEL

PROJECTETEMPS DE DETECCI DERRORS

FI DEL PROJECTE

Fases concretesFases abstractes

Costos baixos

EVOLUCI DEL PROJECTE

Figura 1.2.: Costos del desenvolupament dun projecte

per qu aquestes activitats tenen lloc a les primeres fases i ajuden molta concretar i pensar; i, per tant, a prendre bones decisions sobre elsistema concret durant les fases abstractes.

1.3 Resum i continuaci

En el captol segent es veur el modelat de sistemes de pas de missatges, ambmemria local a cada procs. Aquests sistemes no tenen memria compartida.Serveixen, entre moltes altres aplicacions, per modelar arquitecturesmultiproces-sador, per poden aplicar-se tamb per modelar hardware. Per exemple, rbitresde busos de memria, els quals coordinen els processadors que hi estan dialo-gant. Els exemples mostren com aquestes tcniques es poden aplicar a modelarprotocols de xarxes de comunicaci i cues hardware delements digitals.

El captol de sistemes amb memria compartida resumeix tcniques de modelati de verificaci de programes que corren sobre computadors multiprocessador,els quals es comuniquen intercanviant dades via memria compartida. Es veuruna manera de formular algunes propietats importants i es donaran tcniquesde verificaci basades en la mquina de transicions finites (MTF), la qual serassociada a cada model duna forma sistemtica.

En el captol dexemples al voltant de lexclusi mtua, es mostren intents per talde garantir lEM aix com solucions efectives. Fins aquest punt sha pensat en unnivell real de programes mquina corrent sobre multiprocessadors.

El modelat i verificaci amb semfors s introdut en el captol segent. Aqu lesoperacions del semfor formen un nucli de sistema operatiu. Sest treballantsobre multiprocessadors amb memria compartida.

5

En el captol sobre monitors tamb sest treballant amb sistemes de memriacompartida. Un monitor s vist com una generalitzaci del semfor; s un sem-for programable. Les mquines de transicions finites serveixen tamb per or-ganitzar les demostracions. Per poder fer-ho es dna una forma sistemtica perobtenir les transicions de la MTF dun sistema amb monitors; se les associa acerts fragments de les operacions de monitor.

Finalment, un captol dedicat a donar idees sobre la realitzaci de monitors tancaels apunts. Es veu com el monitor pot ser realitzat sobre bases diferents. Enuna delles, els monitors es realitzen directament sobre la mquina. Aquesta re-alitzaci mostra com els monitors poden ser la base de lorganitzaci de sistemesoperatius, treballant directament sobre els processadors, per fer-los ms clars iverificables.

Lapndix A exposa les construccions seqencials de la notaci de modelat PADD.s necessri conixer-les per entendre el captol 2, el qual entra directament enles construccions de parallelisme i comunicaci, suposant conegudes les seqen-cials.

Lapndix B presenta un model complet duna xarxa de comunicaci. Ofereixals seus clients diversos serveis: Unicast, Broadcast, etc. Integra la majoria deconstruccions i nocions presentades en els apunts. El lector el pot consultar,durant lestudi, per veure ls a la prctica de parallelisme, comunicaci sncrona,memria compartida i distribuda, semfors, monitors, etc.

El model sha dissenyat i programat en el Grup de Recerca en Sistemes Distributs(GRSD) del Departament dInformtica dEnginyeria La Salle, Universitat RamonLlull. s usat i actualitzat en el GRSD per estudiar i mesurar el comportamentdalgorismes de control de concurrncia en bases de dades distribudes.

Continuaci de lestudi. Els apunts fan un esfor per exposar detingudamenti amb claredat els conceptes fonamentals per modelar i verificar. Aix perme-tr lestudi daltres llibres. Caldria aprofundir, especialment en la verificaci. Perfer-ho es donen a continuaci algunes fonts. La verificaci en els apunts segueixlestil de [16, 17], per tant aquests dos llibres sn molt indicats per ampliar coneix-ements. Hi ha altres llibres que exposen ms temes i exemples. Entre ells elssegents: [3] i [20] per estudiar ms sobre programes distributs, [1] verificacialternativa de models concurrents i distributs, [18] programaci concurrent en Ci altres notacions, [5] verificaci de programes concurrents. Una perspectiva delsinicis de la programaci concurrent, amb articles pioners, es troba a [9].

La verifcaci de sistemes amb un nombre finit destats es fa automticamentsobre la mquina de transicions finites (MTF), presentada i treballada en aquestsapunts, amb els vercadors de models, tamb coneguts commodel checkers. Undells s SPIN, exposat a [12]. Per fer-los funcionar cal expressar les propietatsen lgiques temporals. La referncia [16] explica detingudament una delles, laLTL, de linear time logic. Sobre verificadors de models hi ha els llibres [4] i [2], elsquals tamb inclouen presentacions de lgiques temporals.

6

2 Modelat de sistemes prpiamentdistributs

2.1 Introducci

El modelat de sistemes, tant distributs com concurrents, es fa amb notacionsespecials, de modelat. Encara que nhi ha moltes, en aquests apunts treballaremsolament en aquelles que sn imperatives i tenen parallelisme explcit i comuni-cacions amb sincronisme entre receptor i emissor. Un treball pioner s el de Hoare[11]. Les notacions OCCAM [13, 14, 15] , Promela del verificador SPIN [12] i SPL[16, 17] pertanyen a aquest grup. Hem integrat les construccions fonamentals detotes elles en la notaci PADD (de parallelisme, abstracci i disseny dimension-al). En aquest captol sintrodueixen aquestes construccions PADD fonamentats,aquelles que sn imprescindibles pel modelat de sistemes distributs. Sn novesper aquells de vosaltres que coneixeu solament la programaci seqencial. Lessentncies corresponents a la programaci seqencial sn tractades en lapndixA. En altres captols es tracten les construccions que es fan servir pel modelat desistemes amb memria compartida. Bsicament sn el semfor [7] i els monitors[10]. PADD tamb les t, a ms a ms de les anteriors. Aix es poden modelar enaquesta notaci tant sistemes concurrents com distributs.

La noci de procediment modular, surt en tot model, el qual sempre est formatper un conjunt dells. T aspectes relatius al parallelisme, encara que com acas particular s usat en programaci seqencial. Lapartat segent en dna unresum. Tamb s tractat a lapndix A.

2.2 Procediments modulars

Introducci

Un procediment modular s una part de programa, una sentncia, a la qual lidonem un nom per ser invocat dins algun altre procediment; per exemple delprograma principal. El motiu del nom procediment modular s el devitar con-fusions amb el procediment usual de la programaci seqencial, el qual ns uncas particular. Dara en endavant susar el mot procediment per referir-se a unprocediment modular.

Per introduir el procediment, sha de parlar de conceptes que es defineixen poste-riorment, a lapartat 2.3. Aquests sn la composici en parallel de processos i laconnexi. La primera defineix que dos parts dun programa poden dur-se a termesimultniament. La connexi defineix un punt de comunicaci entre processos

7

composats en parallel; per on passaran missatges. Amb aquesta idea generalpodeu entendre el que sexposa aqu sobre procediments.

Estructura global

int

... definici de la interfciealg

... cos de lalgorisme

Figura 2.1.: Estructura dun procediment modular

Lalgorisme i la interfcie sn les dues parts principals dun procediment. Figurencom a subarbre diagonal inferior de les paraules clau alg i int, respectivament,figura 2.1.. La interfcie defineix els punts de comunicaci entre el procediment ila resta del programa. Aquests punts poden ser variables i/o connexions. Les vari-ables defineixen posicions de la memria per al pas de valors. Aquesta memriapot estar compartida amb altres processos parallels. Les connexions serviranper comunicar valors a processos connectats en parallel, sense intervenci de lamemria compartida. La comunicaci prpia t lloc dins lalgorisme del procedi-ment, al dur a terme les sentncies dassignaci i/o les de comunicaci. Per tant,la interfcie s esttica i lalgorisme s dinmic.

La interfcie dun procediment

La interfcie defineix lacoblament, relaci o connexi, del procediment amb laresta del programa. Aquesta definici es fa amb variables i connexions, tant perles entrades com per les sortides:

int

res

Declaraci de resultatsposPostcondicions relacionantresultats i parmetres

parDeclaraci de parmetres

prePrecondicions imposadesals parmetres

algCos de lalgorisme

Figura 2.2.: Interfcie dun procediment modular

La interfcie t dues parts definides en diagonal per sota les paraules clau par, elsparmetres o entrades, i res, pels resultats o sortides, tal com indica la figura 2.2..

8

Lmbit de les variables i les connexions definides a la interfcie s lalgorisme delprocediment. Les variables definides a la part par, com a parmetres, no podenser modificades pel procediment; a no ser que tamb estiguin definides a la partres. Solament les variables a la part res poden ser modificades per lalgorismedel procediment.

El procediment pot estar composat en parallel amb altres processos. Si les varia-bles estan a la memria compartida, els canvis del valor duna variable, realitzatsper altres processos, sn vistos dins el procediment. No cal tornar a entrar pera veurels. De la mateixa forma, tot canvi de valor fet pel procediment a unavariable definida a la part res s vist immediatament per qualsevol procs paral-lel que la consulti; no cal que el procediment retorni. Per tant, les variables a lainterfcie sn passades per referncia i no per valor.

Una altra forma dintercanvi de valors dun procediment amb la resta del pro-grama s mitjanant connexions. Aquesta s la forma corresponent a un sistemaprpiament distribut, carent de memria compartida. Les connexions han destardefinides a la interfcie. Com a parmetres, si per elles el procediment rebr val-ors de processos parallels, o com a resultats si per elles el procediment enviarvalors.

La interfcie pot tenir tamb precondicions i postcondicions. Les precondicionsposen condicions que han de complir els parmetres. Es defineixen a la diagonalinferior de la paraula clau pre. Les postcondicions informen sobre els resultatsdesitjats en funci dels valors dels parmetres. Es defineixen a la diagonal infe-rior de la paraula clau pos. Per aquests apunts, tant les precondicions com lespostcondicions, es defineixen com a comentaris. Formen part de la documentacidel procediment.

Referncia a un procediment

La forma daquesta sentncia s la segent:

r1, r2, ... := Proc.Nme(p1, p2, ...).

Una referncia a procediment serveix per iniciar lexecuci del procediment en elpunt de la referncia. La sentncia t la llista de resultats a la part esquerra, elsmbol dassignaci a la dreta, continuant amb el nom del procediment i la llistade parmetres, a la dreta del nom. Lordre a les dues llistes ha de correspondreals de la interfcie del procediment referenciat.

2.3 Parallelisme i comunicaci

Introducci

A ms a ms dels procediments modulars, les sentncies pel modelat de sistemesamb parallelisme i comunicaci sn la composici en parallel, la declaraci deconnexions, les operacions de comunicaci i la selecci de comunicacions. Sex-pliquen a continuaci.

9

Parallelisme

La definici del parallelisme entre processos s explcita en la notaci mitjanantla sentncia de composici en parallel. La figura 2.3. en dna un exemple com-posant N processos, sentncies, en parallel:

. . . sentncies sequencialment anteriors al parallelisme| |

P1Sentncia de P1

P2Sentncia de P2

... PNSentncia de PN.

. . . sentncies sequencialment posteriors al parallelisme

Figura 2.3.: Estructura dun parallelisme

En aquesta sentncia, els processos tenen una etiqueta dencapalament, (P), iestan connectats horitzontalment entre ells. El smbol || representa la totalitatde la sentncia de parallelisme, usualment formant part, tota ella, duna sentn-cia de composici en seqncia. La llista horitzontal de processos s el subarbreen diagonal, o sigui, el refinament diagonal del node del smbol de parallelisme.El cos de cada procs (sentncia de Pi) pot ser definit explcitament o be amb unareferncia a procediment. En el segon cas, la definici esta encapsulada dins elprocediment.

Lexecuci del parallelisme sinicia creant i fent comenar tots els seus processos.Lordre relatiu dexecuci de les subsentncies dels processos pot ser qualsevol:s desconegut; per ha de respectar el seu ordre dins cada procs. Lexecuci delparallelisme acaba solament quan tots els processos han acabat, i continua ambla sentncia seqencialment posterior al parallelisme, o sigui, la connectada coma subarbre seqencial del smbol ||.

La semntica del parallelisme sexposa amb ms detall en el captol 3. s unasemntica dentrellaaments de les subsentncies de cada procs.

Connexions

Els processos composats en parallel poden comunicar-se per connexions, decla-rades abans del parallelisme corresponent a lemissor i al receptor. Lesquemade la figura 2.4. illustra la declaraci de connexions. Les connexions sn usadespels processos en parallel per enviar i rebre valors, de forma sncrona; tal comsexplica a lapartat segent.

La sentncia con, figura 2.4., declara connexions per ser usades ms avall enlalgorisme. Lmbit o zona on es poden usar les connexions s el subesquemavertical del node de con. Sn invisibles en qualsevol altre lloc.

Les connexions es declaren amb el seu tipus. El tipus de la connexi buida s nul.

La sentncia con amb un paral.lelisme en el seu mbit, on els processos paral.lelses comuniquen per les connexions declarades, constitueix el marc per definir unaxarxa de processos comunicants.

10

con

con1: TypeCon1con2: TypeCon2. . .

| |P1. . .

. . . PN. . .

Figura 2.4.: Declaraci de connexions

Encara que les connexions sn tipades, no tenen cap buffer. Sn punts sensememria que fan possible la comunicaci half-duplex de punt a punt, entre dosprocessos paral.lels.

Les connexions que comuniquen un procediment amb altres processos paral.lels,sn declarades a la interfcie del procediment, a ms a ms de les variablesparmetre o resultat (per memria compartida), tal com sha exposat abans.

Les connexions dentrada tenen noms amb el prefix "", i han de declarar-se enlapartat de parmetres.

Les connexions de sortida tenen noms amb el prefix "[]", i han de declarar-se alapartat de resultats.

Aquestes connexions sn usades dins de lalgorisme del procediment. Arrays uni-dimensionals de connexions tamb es poden declarar, com sexposa ms avall.No hem de confondre una connexi amb un canal, el qual s modelat com unprocs. Un altre nom per les connexions s canal sncron.

Operacions de Comunicaci. Enviar i rebre

El succs real de la comunicaci dun valor sespecifica amb operacions de comu-nicaci, dins lalgorisme dels processos composats en paral.lel. Hi ha les opera-cions enviar i rebre. Sanomenen parell abstracte de comunicaci (PAC).

Cada tipus t associat un PAC amb les seves dues operacions complementries,enviar i rebre. Serveixen per comunicar valors del tipus. La forma concreta comla comunicaci t lloc s desconeguda; aquesta s la motivaci per la paraulaabstracte.

Donades c : t i : t, una connexi i una variable de tipus t, susar la sintaxisegent per les operacions denviar i rebre, respectivament:

:=c i []c := .

La sintaxi segent susar per les comunicacions tipades amb nul:

c i []c.

En aquest cas no es passa cap valor, noms dos senyals de sincronitzaci. Aques-tes fan que un dels processos, el que ha arribat a la sentncia de comunicaci,esperi a que laltre hagi arribat a laltra operaci de comunicaci.

11

La comunicaci t lloc sense cap buffer intermedi; els dos processos sincronitzena les seves operacions de comunicaci. El primer procs que arriba a la operacide comunicacions espera laltre. Quan les dues estan a punt per comunicar, elvalor de tipus t, que s a la variable de la sentncia demetre, s guardat a lavariable de loperaci de rebre. Un cop passat el valor, lexecuci continua enparal.lel.

Selecci de comunicacions estndard

La sentncia de selecci de comunicacions t alternatives connectades en unallista horitzontal. Solament una de les alternatives ser escollida per execu-tar. La selecci daquesta ve determinada per condicions booleanes (guardesbooleanes), b, i per operacions de comunicaci (guardes de comunicaci), c,situades en els encapalaments de les alternatives. La selecci depn de lava-luaci de les condicions i de les possibilitats de comunicaci amb el processosvens, implicats per les connexions. La disjunci lgica de totes les condicions hade valer cert en totes les possibles execucions de la selecci. Si no s aix, tlloc un acabament amb error. La figura 2.5. illustra la sintaxi de la selecci decomunicacions:

...

?

b1, c1A1

b2, c2A2

...

bn, cnAn

...

Figura 2.5.: Selecci de comunicacions

Lexecuci es fa de la manera segent:

Per cada alternativa, comenant per la de ms a lesquerra, el boole bi savaluat.

Si val fals, lalternativa segent s examinada.

Si val cert, savalua lestat de loperaci de comunicaci ci :

Si est a punt, llavors t lloc lesdeveniment de comunicaci i lalter-nativa corresponent s seleccionada per executar.

Si no ho est, sinspecciona lalternativa segent, per la comuni-caci es deixa oberta".

Finalment, un cop totes les alternatives shan examinat sense que cap es-tigui a punt per comunicar, el procs que duu a terme la selecci espera laprimera comunicaci, de les obertes, que vulgui comunicar.

Al menys, una de les guardes ha de valer cert, si no un error t lloc. Per tant,al menys, una operaci de comunicaci s inspeccionada. Resumint, el procsseleccionar lalternativa de ms a lesquerra que tingui una condici booleana

12

certa i una comunicaci a punt. Quan cap est a punt, es selecciona lalternativaamb condici certa i que tingui primer la seva comunicaci a punt.

Selecci de comunicacions amb timeouts

...

?

b1, c1A1

b2, c2A2

...

bn, delay(t)An

...

Figura 2.6.: Selecci de comunicacions amb timeout

Quan la guarda de comunicacions duna alternativa s delay(t), el procs de laselecci activar delay(t) solament quan la guarda booleana corresponent valcert. En aquest cas, quan activa delay(t), espera larribada duna comunicaci. Eltemps darribada s t unitats de temps desprs de lactivaci de delay(t). Aix potveures com una comunicaci que ve dun procs, amagat, rellotge-despertador,el qual ha estat inicialitzat quan el procs de la selecci activa delay(t). Si abansdaquest temps arriba una altra comunicaci oberta de la selecci, la selecciescull aquesta alternativa; al mateix temps desactiva el despertador.

Una selecci de comunicaci pot tenir ms duna alternativa daquest tipus i po-den estar en qualsevol de les alternatives. Sescull lalternativa amb menor tempsdespera. La figura 2.6. illustra la sintaxi daquest tipus de construcci PADD.

Estructures iterades

Vectors de connexions

Els vectors de connexions han de declarar-se dins lmbit dun con. Amb la sintaxisegent: conName(inx0 .. inxEnd):ConType. Per exemple, ot(0..4) : nteger.

Tamb poden declarar-se a la interfcie dun procediment. En aquest cas, essegueix la mateixa sintaxi per ampliant el nom del vector amb els prefixos o b [], segons sigui dentrades, a la secci par o de sortides, a la secci res.Per exemple n(1..7) dins lmbit dun par.

Per referir-nos a un element dun vector, es fa de la manera usual. Per exemple, nCon(5) i []ot(2). Aquestes referncies poden estar dins de les sentnciesenviar i rebre, o b dins una referncia a procediment, com a resultat (enviar) ocom a parmetre (rebre).

Si volem passar tot un vector de connexions a un procediment, hem de posar sola-ment el nom del vector al lloc adient de la sentncia de referncia a procediment.El nom ha dampliar-se amb els prefixos o b [] pels vectors dentrada,llista de parmetres, i pels vectors de sortida, llista de resultats, respectivament.

13

Iteracions de parallelisme

Donen una representaci concisa i paramtrica duna sentncia de parallelisme.Aix estalvia molt de temps; cal tan sols canviar una variable entera per tenirel nombre de processos parallels que ens calgui. Per poder usar la sentnciade parallelisme iterat, paramtric, cal que tots els processos parallels siguinidntics, exceptuant un ndex. Per indicar que una sentncia s una iteraci deparallelisme es juxtaposa al smbol de parallelisme el nom de lndex i lintervalde valors que ha de prendre. La sintaxi s la segent

|| parameter name := rst value .. last value.

Per exemple, ||k := 0..n o b || := 1..7.

En el refinament daquest node hi ha de figurar un sol procs, el qual usa lndex.El sistema generar un parallelisme, com els dabans, amb tots els processosobtinguts en fer variar el valor de lndex dins linterval especificat al costat delsmbol de parallelisme.

Aniuament de parallelismes

Corresponen a sentncies de parallelisme les quals inclouen sentncies del mateixtipus, amb iteraci o sense iteraci. Aquestes sentncies sempre indiquen una so-la sentncia horitzontal de parallelisme. Una sentncia aniuada inclou nodes delmateix tipus, tots sn parallelismes. Un possible exemple es mostra a la figura2.7.:

| || | k:=1..n

A(k) B| |

| | l:=1..mC(l)

| | i:= 0..rD(i)

Figura 2.7.: Un exemple de parallelisme aniuat

Aquest exemple de parallelisme aniuat s equivalent a un parallelisme ambn+m+ r + 2 processos en parallel.

2.4 Exemples

Una cua per comunicar processos

Aquest apartat ensenya a modelar sistemes distributs. Ho fa mitjanant exem-ples. El primer exemple modela una cua dtems (poden ser missatges, strings,

14

enters, etc...), la qual t aplicaci per comunicar processos. La comunicaci ambuna connexi, com sha vist anteriorment, sincronitza el procs emissor i el re-ceptor; solament passen un tem quan els dos tenen el control a les sentnciesde comunicaci respectives. La cua daquest exemple presta un servei de comu-nicaci on els processos no han desperar al receptor quan emeten un missatge,sempre que hi hagi lloc a la cua. Tampoc els processos receptors han desperaral procs emissor, quan hi ha tems a la cua. Per tant, aquesta cua ofereix unacomunicaci on els processos estan desacoblats i desincronitzats.

La cua t longitud finita, solament poden guardar un nombre finit dtems. Quan lacua est plena, el procs emissor ha desperar a que el procs receptor semportiun tem de la cua, amb el qual fa lloc per ltem que vol passar el receptor. Tamba linrevs, el receptor haur desperar a que hi hagi al menys un tem a la cua,quan la cua s buida.

Les cues daquest apartat tamb es poden fer servir com a models dun canal decomunicaci duna xarxa, quan es vol que lordre dels missatges rebuts sigui elmateix que lordre en el qual lemissor els ha deixat al canal. Tamb, a ms ams, es permet que hi hagi simultniament a la cua un nombre finit dtems. Elsmodels sn lliures derror i de prdues.

Les cues amb solament un tem sn un model alternatiu i equivalent al protocolde parada i espera descrit ms endavant en aquesta secci. Els mecanismes deretransmissi, en cas derror o de prdua, faran que aquell model sigui equivalentals daquest apartat.

Cua amb parallelisme intern

El primer exemple est format composant en parallel N registres. Els registresestan connectats en srie, el qual els fa comportar com una cua. Aquest modelel mostra la figura 2.8.. Es remarca que els models de les dues figures sn duesformes dexpressar la mateixa cua. En aquesta ltima no cal modificar el modelquan el valor de N canvia.

QueParint

res

[]out: Itempar

in: Itemalg

con

c(1..N-1): Item| |

Register1var

mem: Item*

mem:= c(1)[]out:= mem

Register2var

mem: Item*

mem:= c(2)[]c(1):= mem

. . . RegisterNvar

mem: Item*

mem:= in[]c(N-1):= mem

Figura 2.8.: Cua amb parallelisme intern

15

Cada un dels registres t la seva variable local mem on hi guarda el seu tem,el seu estat. El seu comportament s expressat com una iteraci indefinida. Laprimera sentncia del cos de la iteraci s un rebre, o entrada, del registre ve dela seva dreta. La segona sentncia s un emetre del seu tem al ve de la sevaesquerra.

Els registres dels dos extrems sn especials. El de lesquerra emet un tem per laconnexi out. El de la dreta rep un tem per la connexi in. Les dues connexionssn externes, respecte a la cua, i estan declarades en la interfcie.

El model anterior solament pot ser expressat per un nombre concret de registres.Per tenir un model ms flexible, expressarem el model en funci de N, el nombrede registres, el qual s un parmetre ara. Emprarem literador de parallelisme,com mostra lesquema de la figura 2.9.. Correspon a una cua general amb Nregistres. N s un parmetre que pot prendre valors de 2 en endavant.

QueueItParint

res

[]out: Itempar

in: ItemN: Integer

preN>1

algcon

c(1..N-1): Item| | k:=1..N

var

mem: Item?

k=1*

mem:= c(k)[]out:= mem

k>1 AND k

dues de comunicaci per la mateixa connexi, una a cada procs, dels registresque comuniquen. Tamb considereu que una execuci s un entrellaament delstoms de cada procs, el qual respecta lordre dels toms a cada un dels proces-sos. Tot aix es treballa detalladament al captol 3.

Cua sense parallelisme intern

SeqQueueint

res

[]out : itempar

in : itemalg

var

b : queuenew : item

InicialitzaciN:= 8b:= MkQueue()

* ?

NOT IsEmpty(b), []out:= FirstQue(b)b := DelFirst(b)

NOT IsFull(b), new:=inb := InQueue(new,b)

Figura 2.10.: Cua sense parallelisme intern

La figura 2.10. mostra el model de la cua sense usar parallelisme. Modela unacua amb comportament idntic al de la dabans. Farem servir un tipus abstractede dades (una classe), queue, que suposarem ja programat amb programaciseqencial usual. Les operacions del tipus abstracte sn les segents:

MkQueue, crea i retorna la cua buida.

InQueue, afegeix un element al final de la cua.

DelFirst, esborra el primer element de la cua.

FirstQue, dna el primer element de la cua; sense esborrar-lo de la cua.

NonEmpty, dna cert si la cua no s buida.

NonFull, dna cert si la cua no est plena.

El model tamb s un exemple ds de selecci de comunicacions. Les sevesalternatives tenen la mateixa forma. Aquesta selecci no fa servir cap crida adelay(t).

El cos del bucle indefinit cont la selecci de comunicacions. Les dues guardesbooleanes aturen tot procs que vol treure un tem quan la cua s buida, i aturentamb tot procs que vol encuar un tem quan la cua s plena.

17

Tant la sortida com la entrada poden estar obertes en el mateix estat; naturalmentsescollir una sola alternativa.

Fixeu-vos com no hi ha cap estat de la cua on les dues guardes booleanes tinguinel valor fals. Si nhi hagus algun seria un error de programaci.

El comportament o semntica dexecuci daquest model, vist de lexterior de lacua (dels processos emissor i receptor), s el mateix que el del model de cua ambparallelisme intern exposat abans. Comproveu-ho vosaltres amb traces.

Protocol de parada i espera

Continuem exposant exemples a fi de concretar el significat de les construccionsde la notaci de modelat. Lexemple ara s el model dun canal denlla, punt apunt, de parada i espera (stop-and-wait). Aquest canal podria ser, per exemple,un component del model duna xarxa.

La figura 2.11. mostra el model, el qual el formen quatre processos composatsen parallel: emissor, receptor, canal de dades i canal de reconeixement de tor-nada (acknowledge). Aquests quatre processos comuniquen per connexions tantentre ells com amb lexterior. Aquest el suposem format per dos processos, clientreceptor i client emissor.

E(et)

Emtter

Ce(pe, p, t, t)

DtChne

C(p, t, t)

AckChne

R()

Receer

o

s

ke

er r

kr

L2Chne

Figura 2.11.: Canal de nivell 2

Els processos emissor i receptor sn els que realitzen el protocol, prpiament.Els altres dos sn models del comportament del canal o xarxa real. El conjunt,incloent els dos clients, funciona com a banc de proves de lemissor i el receptor.El protocol t un timeout per acabar la espera del reconeixement que fa lemissor.

Lesquema de la figura 2.12. descriu solament les connexions entre els quatre pro-cessos i amb lexterior format pels dos clients. Els comportaments dels processoses defineixen en els procediments E, Ce, C i R. Alguns daquests procedimentses tracten ms avall. Queden composats en parallel. Les connexions dentradai sortida de cada procediment queden definides en les respectives sentncies dereferncia a procediment. Correspon al diagrama de blocs de la figura 2.11..

Aquest exemple exposa solament una forma de definir processos parallels. Enaquest un procs es defineix en un procediment, la invocaci del qual s una

18

sentncia de referncia a procediment. No obstant, existeix una altra opci senseprocediments: la definici explcita en el mateix procs composat en parallel.Aquesta opci ha estat usada en el primer exemple, la cua realitzada amb paral-lelisme intern.

L2Channelint

res

Sortida vers el client[]o : message

posEls missatges surten en el seuordre dentrada, i sense canvis.El procediment no acaba mai.

parEntrada del client

i : messageProbabilitats derror i de prdua

pe: realpl: real

Temps dins el canal i entre carcterstl: realt: real

Temps desperaet: real

pre0 < pe, pl < 1tl, t, et >= 0

algcon

s, r, akr, ake : packeter : nul

| |Emitter

[]s:=E(i,ake,et)DataChannel

[]r,[]er:=Cel(s,pe,pl,tl,t)AckChannel

[]ake:=Cl(akr,pl,tl,t)Receiver

[]o,[]akr:=R(r,er)

Figura 2.12.: Procediment principal del model

Lesquema defineix el canal L2Chanel com un procediment. La seva interfcie diuque: valors de tipus message entren del client emissor (no representat explcita-ment) per la connexi dentrada ; tamb que els valors sn passats al procsclient receptor (tampoc representat explcitament) per la connexi de sortida []o.El parallelisme composa els quatre processos. Cada un dells invoca un procedi-ment. Recordeu que en la invocaci dun procediment es passen solament dretsde comunicaci; el comportament real del procs es concreta amb sentncies decomunicaci dins la part algorsmica de cada procediment.

El model del canal de dades el teniu a la part algorsmica del procediment Cel, elqual s tractat ms endavant. Transmet missatges de lemissor al receptor. Incloula possibilitat derrors de transmissi i de prdua de missatges. Les probabilitatsderror de transmissi i de prdues es defineixen en les variables dentrada pe i p,respectivament. Els temps de retard del primer carcter dun missatge es defineixen la variable t. El temps addicional per a cada nou carcter del missatge esdefineix en la variable t. El temps mxim despera del missatge de reconeixementcorrespon a la variable et. Totes aquestes variables sn parmetres.

El diagrama anterior defineix aspectes esttics solament, o sigui, el graf del di-agrama de blocs de ms amunt. El funcionament del canal global L2Channel, osigui, la dinmica de les comunicacions, quedar definida dins la part algorsmicade cada un dels procediments. El procediment L2Channel defineix els quatre pro-cessos parallels i invoca els quatre procediments. El procediment no acaba maidoncs, com veureu, lalgorisme dels quatre procediments s, bsicament, unaiteraci indefinida. Per tant, cap procediment acaba i el control mai s retornat a

19

L2Channel.

Lemissor passa paquets al canal de dades per la connexi s. Tamb, rep missat-ges del client emissor per la connexi . Els paquets de reconeixement, positiu onegatiu, entren a lemissor per la connexi ke, la qual surt del procs ackchan-nel. Els paquets que arriben amb error del canal de dades, datachannel, es mo-delen activant la connexi er, de tipus nul, declarada localment en lalgorismedel procediment L2Channel. Aquestes connexions internes no sn visibles fora deL2Channel.

Un paquet t lestructura segent:

- - - - -

Type: {"ack", "nack", "dta", . . . }

header info: message

Lemissor

Lesquema de la figura 2.13. correspon al process emissor. Lalgorisme inicialitzalestructura dun paquet dins el procediment constant Mkpacket; suposem queposa a la capalera els camps necessaris: adreces de lorigen i del dest, tipus"dta", etc...

En lalgorisme, desprs de rebre un missatge del client i posar-lo al camp info delpacket, entra en una iteraci indefinida. El cos daquesta iteraci comena eme-tent el paquet que cont el missatge rebut. Es fa per la connexi que internamentsanomena se i que a L2Channel es coneix com a s.

La primera selecci del cos de la iteraci te dues alternatives, una per acceptar elpaquet de reconeixement per la connexi ack i latre per acceptar la fi del tempsdespera mxim, timeout, del reconeixement. La primitiva delay (timeout) inicial-itza el rellotge-despertador ocult i, si el temps mxim despera ven, accepta elmissatge i escull la segona alternativa, la qual passa el control a linici del cos dela iteraci on es retransmet el mateix paquet.

Doneu-vos compte que la retransmissi succeeix en dos casos, quan no es repcap missatge de reconeixement o quan es rep un missatge de reconeixementnegatiu, "nack". En el cas usual de rebre un paquet de reconeixement propi, enlalternativa corresponent saccepta un nou missatge del client emissor.

Model del canal de dades

El diagrama de la figura 2.14. modela el canal de dades. Els paquets entren perla connexi in, la qual correspon a la s de L2Channel. El model t un mecanis-me per acceptar paquets de lemissor en tot moment; encara que lemissor no

20

Eint

res

[]se : packetposCada paquet que entra per in s enviat per []se,llavors hi ha tres comportaments possibles:1. Es reb un reconeixement per ack2. Ee reb un reconeixement negatiu per ack.Llavors s enviat novament3. Acaba el temps despera del reconeixement.Llavors s enviat novament

parin : messageack : packettimeout : real

pretimeout s no negatiu.

algloc

e : packetb : packet

Inicialitzacie := Mkpacket()

Acceptar el primer missatgee.info := in

* []se := e?

true, b := ack?

b.type = "ack"e.info := in

elseRetransmetre

Nil

true, delay ( timeout )Retransmetre

Nil

Figura 2.13.: Model de lemissor

21

Celint

res

[]out : packet[]err : nul

posCada paquet entrat per inT quatre possibilitats:1. s sobreescrit2. s perd amb probabilitat pl3. Aarriba amb error,amb probabilitat pe x (1-pl)4. Aarriba correctament,amb probabilitat (1-pl)x(1-pe)

parin : packetProbabilitats derror i de prdues

pe: realpl: real

Temps de transmissi del primer carcter i entre carcterstl: realt: real

pre0 =< pe, pl =< 1

algvar

p : packetAcceptar el primer paquet

p := in*

?

true, p := inEl paquet actual ha estat sobreescrit

nil

true, delay ( tl+t*length(p) )?

randTrue(pl)Prdua

nil

else?

randTrue(pe)Error

[]err

elseArribada correcta

[]out := pAcceptar un paquet nou

p := in

Figura 2.14.: Model del canal de dades

22

envia un segon paquet mentre no hagi rebut el missatge de reconeixement delprimer. El banc de proves ha de servir per detectar tot tipus derror. Per exemple,penseu que lemissor estigui mal programat i envia paquets abans de rebre elscorresponents reconeixements. Llavors, grcies al mecanisme anterior, el canalels acceptaria i aix podem posar, en el canal de dades, indicadors daquest error,per adonar-nos-en.

El canal de dades t dues connexions de sortida. La out, per enviar al receptorels paquets sense error, i la err, per indicar-li que un paquet arriba amb error.En aquest ltim cas s suficient el sincronisme de la comunicaci, el qual farentrar al receptor en el punt de control que actua quan rep un paquet erroni.Fixeu-vos com les dues comunicacions de sortida sn guardes duna selecci decomunicacions. Tant aquestes dues connexions com lanterior sn declarades ala interfcie del procediment Cel.

Lestructura principal de lalgorisme s similar al de lemissor: una iteraci in-definida, el cos de la qual s una selecci de comunicacions de dues alternatives.La primera permet que el canal accepti paquets de lemissor en tot moment; aixes duu a terme el mecanisme exposat ms amunt. En aquest cas, el delay de lasegona alternativa modela el temps de transmissi. Quan lemissor esta ben pro-gramat, no envia un nou packet al canal de dades fins no rebre el reconeixementi, per tan, sescull la segona alternativa.

El punt de control immediatament posterior al delay correspon a larribada delpaquet al receptor. Hi figura una selecci normal amb dues alternatives seguida,en seqncia, per una comunicaci dentrada. Aquesta comunicaci accepta unnou packet de lemissor quan el paquet anterior ja ha estat processat pel canalde dades.

La primera alternativa modela la prdua dun paquet. La probabilitat de prduas pl. El modelat de probabilitats amb el procediment randTrue s exposat breu-ment en lapartat segent. La segona alternativa modela larribada dels paquetsque no han estat perduts pel canal de dades. Com es veu, els paquets no perdutsarriben amb error amb probabilitat pe.

Modelat de probabilitats

El modelat de probabilitats s un tema important i extens que aquests apunts nopoden tractar. Es basa en procediments bsics que donen nombres aleatoris ambfunci de densitat uniforme. En lexemple del canal de dades aquesta funci bsi-ca s ndst(m, ), la qual suposem existent. Al cridar-la ens dna, al retornar,un nombre aleatori entre m 2 i m +

2 amb igual probabilitat. Amb funci de

densitat uniforme entre m 2 i m +2 . Podem dir que ndst(m, ) val aquest

nombre. Al cridar aquest procediment molts cops, els nombres que ens dna sndiferents, per estan dins linterval anterior amb equiprobabilitat.

En el procediment randTrue del diagrama, els parmetres de ndst(m, ) snm = 0,5 i = 1. Per tant, els nombres aleatoris que retorna estan uniformementdistributs entre 0 i 1.

Al al ser 0 p 1, p sempre estar dins linterval dels nombres aleatoris quedna unifdist. Llavors, la desigualtat ndst(0.5,1) < p, i la variable b resultatde randTrue, seran certes amb probabilitat p.

23

randTrueint

res

b: Booleanposb cert amb probabilitat p

parp: real

pre0 =< pp =< 1

algb:= (unifdist(0.5, 1) < p)

Figura 2.15.: Procediment boole per generar cert amb probabilitat p

Els altres procediments

Faltaria donar els procediments del receptor i del canal de reconeixements deretorn. Us animem a fer-los vosaltres. Heu de fer-los de manera que treballin bamb els altres, que no hi hagi atur indefinit. Totes les comunicacions han de podersincronitzar.

El receptor R, quan rep un paquet sense error, emet el reconeixement positiu alcanal de retorn C i passa el missatge corresponent al client receptor. En cas derebre un paquet amb error ha denviar un paquet de reconeixement negatiu a C.Podeu fer un canal de retorn ms senzill que el canal de dades: sense prdues nierrors.

Finalment, tots els procediments, amb inclusi del L2Channel, poden posar-sedins la part prc dun mdul (exposat a lapndix). Hi hauria dhaver un procedi-ment principal que defins els dos clients i els composs en parallel amb el canalglobal L2Channel.

El problema dels filsofs

El problema dels cinc filsofs s clssic dins el camp de la programaci concur-rent. Per tant, s inexcusable la seva presentaci. En comptes del nmero cincusarem el dos. Ja s suficient per tenir problemes. Tenim un sistema tancat ambdos filsofs i dues forquilles. Un filsof duu a terme solament dues activitats: pen-sar i menjar. Ho fa alternativament i iterativa, per sempre (iteraci indefinida).Com mostra la figura 2.16., per menjar hi ha una taula rodona al menjador, ambdues cadires i dues forquilles al voltant del plat de menjar, situat al bell mig de lataula. Al comenament, tota cadira t dues forquilles damunt la taula a la dretai esquerra de la cadira, preparades perqu, si ve un filsof i seu per menjar, lespugui agafar.

Tot filsof t la seva cadira. Per menjar, seu; llavors necessita les dues forquilles.Si sn lliures les agafa abans de menjar, primer una i desprs laltra. Solamentquan t les dues pot menjar. Quan ha acabat de menjar deixa les dues forquillesi surt del menjador per continuar pensant.

Si al voler menjar un filsof troba una de les seves dues forquilles agafada pel ve,espera fins que s alliberada, quan el company acaba de menjar (en temps finit).

24

P2

F1

P1

F2

Figura 2.16.: El sistema: dos pensadors, dues forquilles i menjar

Mai podem prendre una forquilla quan la t un filsof. Diem, en aquest cas, queel sistema s no preemtiu (non preemtive).

Tal com mostra la figura 2.17., modelarem el sistema amb processos comuni-cants, amb connexions sncrones de tipus Nil. Cada forquilla ser un procs (F1 iF2) i cada filsof tamb (P1 i P2). Les connexions modelen els successos dagafar(T, take) i de deixar (L, leave) forquilles. Per exemple, la pTj modela el succs enel qual el filsof agafa la forquilla j. Tamb la pLj el corresponent al filsof deixant la forquilla j. La direcci de la comunicaci no t cap importncia, doncsel rendez-vous simple s totalment simtric.

F1

P1

F2

P2

p1T1p1L1 p2T1p2L1

p2T2p2L2p1L2p1T2

Figura 2.17.: Model amb quatre processos i vuit connexions

La figura 2.18. mostra el model. Fixeu-vos en el comportament dels filsofs, P1 iP2. Solament ens interessen els sincronismes; les activitats de pensar i menjar lesmodelem amb un nil. Observeu els processos que representen el comportamentde les forquilles, F1 i F2. Tota forquilla est oberta a que lagafi P1 o P2, per uncop agafada per un, solament espera a que lalliberi.

25

algcon

p1T1, p1L1, p1T2, p1L2: Nulp2T1, p2L1, p2T2, p2L2: Nul

| |Filsofs

| |P1

* P1 pensa

NilP1 vol menjarP1 agafa les forquilles

[]p1T1[]p1T2

P1 menja prpiamentNil

P1 deixa les forquilles[]p1L1[]p1L2

P2* P2 pensa

NilP2 vol menjarP2 agafa les forquilles

[]p2T2[]p2T1

P2 menja prpiamentNul

P2 deixa les forquilles[]p2L1[]p2L2

Label 1...

Label 1Forquilles

| |F1

* ?

true, p1T1p1L1

true, p2T1p2L1

F2*

?

true, p1T2p1L2

true, p2T2p2L2

Figura 2.18.: Model del sistema expressat en PADD

26

Hem definit que P1 agafi primer F1 i P2 agafi primer F2, les forquilles de les sevesdretes, respectivament. Aquest sistema no s absent de bloqueig. En altres pa-raules, s possible que els dos filsofs es quedin aturats per sempre. Penseu enel cas on P1 t F1 i P2 t F2. P1 espera F2 (comunicaci per p1T2 pendent) i P2espera F1 (comunicaci per p2T1 pendent), per en aquest estat F1 solamentespera comunicar per p1L1 (alliberament de F1) i F2 solament per p2L2. Capdaquestes dues comunicacions podr donar-se mentre els filsofs no acabin demenjar, per resulta que esperen eternament per comenar a fer-ho.

Per evitar aquest possible bloqueig podem intercanviar lordre de les comunica-cions [ ]p2T2 i [ ]p2T1 a P2. Comproveu que, llavors, el sistema no entra maien lestat de bloqueig.

2.5 Resum

Per construir models de sistemes distributs cal una notaci de modelat. Els mo-dels serveixen per analitzar el comportament del sistema abans de tenir-lo ope-ratiu. Aquesta anlisi es fa sobre el model, tant fent-lo crrer simulant lexecucidel sistema com, tamb, verificant el model. Per tant, primer de tot hem dapren-dre a modelar.

Amb aquest objectiu, aquest captol ha introdut la notaci de modelat PADD,la qual integra les sentncies ms usades en les notacions de modelat actuals:parallelisme, operacions de comunicaci, selecci de comunicacions. La comuni-caci fonamental entre processos parallels s la que sincronitza el procs emissori el receptor per la connexi. Totes aquestes sentncies shan exposat en aquestcaptol.

La noci de procediment modular tamb sha exposat, com a extensi del pro-cediment de la programaci seqencial, amb lobjectiu dusar-lo en models ambparallelisme explcit. Hem vist com aquest tipus de procediment pot definir laseva comunicaci amb processos parallels amb connexions i/o amb variables amemria. El primer cas, en el context de sistemes prpiament distributs. Enel segon cas, per sistemes amb memria compartida; preparant-nos aix pelscaptols segents. El procediment modular s, doncs, un element de modelat in-tegrador de sistemes distributs i sistemes amb memria compartida.

Tots els elements citats anteriorment han estat aplicats en exemples concrets.Primer, sha vist com modelar una cua dtems de mida finita. Sha modelat dedues formes diferents: amb i sense parallelisme intern. En el primer cas, ca-da element de la cua s guardat en un registre, el qual es comunica amb elsregistres vens; aquest model sha expressat de dues formes diferents, en unadelles el nombre de registres s un parmetre. El model que no usa parallelismees fa en funci duna cua seqencial expressada com a tipus abstracte de dades.

El segon exemple ha estat un protocol de comunicaci denviament i espera. Es-t format per quatre processos composats en parallel: lemissor, el receptor, elcanal de dades i el canal de retorn de reconeixements de recepci.

27

Finalment sha explicat un model, totalment distribut, del clssic problema delsfilsofs; no susa cap variable. En ell, les comunicacions per connexions modelenels successos de demanar, adquirir i alliberar les forquilles per part dels filsofs.

2.6 Problemes

Problema 2.1En un sistema multiprocessador amb memria compartida, amb temps unitariper a les operacions suma-assignaci ( := b+c), multiplicaci-assignaci ( :=bc), i temps daccs a memria negligible, es demana transformar el programa

algExemple de clcul aritmtic seqencial

locx, y, v, w, z: real

x:= i + gw:= c * dy:= w * xv:= a * bz:= v + y

en un altre programa que realitzi el mateix clcul, per amb paral.lelismeexplcit. El temps dexecuci del nou programa ha de ser mnim, per tant hadusar-se el mxim paral.lelisme possible.

Soluci Les restriccions a la paral.lelitzaci sn les dependncies de dadesexistents.

algVersi equivalent paral.lelitzada

| |

| |

x:= i+g w:= c*dy:= w*x

v:= a*b

z:= v+y

Observeu com lltima sentncia depn de les que calculen i y, per tant en elnou programa es duu a terme desprs del paral.lelisme dels dos processos queacaben amb les assignacions que calculen les dues variables. Aix tamb escompleix en el cas de la sentncia y :=. El temps de clcul resultant s de3 unitats de temps.

28

Problema 2.2()- Si PA, PB i PC representen les abstraccions PADD dels segments de pro-grama DLX Segment A, Segment B i Segment C, respectivament, representeulabstracci PADD del segment:

. . .ADD r1, r2, r3 sumaBNEZ r1, b branch non-equal zeroSegment AJ c salt incondicional

b: Segment B

c: Segment C. . .

Soluci

. . .

?

r2 + r3 = 0PA

ElsePB

PC. . .

Problema 2.3Doneu el programa dinstruccions del DLX que s equivalent a labstraccisegent:

ra:= 0*

ri > 0ra:= ra + Ma(ri)ri:= ri - 1

end: ...

on r i r sn registres i M s una adrea de memria.

Soluci

ADD ra, r0, r0loop: BEQZ ri, end

LW rm, M(ri)ADD ra, ra, rmSUBI ri, ri, 1J loop

end: . . .

29

Problema 2.4Lesquema segent ha de modelar un pas a nivell en un encreuament de car-retera amb una lnia ferroviria.

var

barrera: {pujada, baixant, baixada, pujant}tren: {lluny, prop, creuant}

con

trenentra, trensurt: Nilbaixa, puja: Nil

| |Tren

* Lluny

tren:= llunydelay(tlluny)

Aproximaci[]trenentratren:= propdelay(taproximaci)

Encreuamenttren:= creuantdelay(tcreuant)[]trensurt

Controladorcompleteu. . .

Barrera* Pujada

barrera:= pujadabaixa

Baixantbarrera:= baixantdelay(tbaixada)

A baixbarrera:= baixadapuja

Pujantbarrera:= pujadelay(tpuja)

Es vol simular el comportament del controlador electrnic de la barrera. Elprocs Tren modela el comportament del tren, el qual pot estar en tres estats:lluny, prop i creuant. La variable que correspon a lestat s tren. El procs Bar-rera correspon a la barrera, la qual pot estar en quatre estats: pujada, baixant,baixada i pujant. La variable corresponent s barrera.

Completeu el model del controlador a fi que mantingui linvariant:

: (tren = crent) (brrer = bd)

per maximitzi el temps durant el qual la barrera est pujada.

Les connexions trenentra i trensurtmodelen els sensors que informen al contro-lador que el tren entra a la zona daproximaci i que lltim vag surt de la zonade encreuament. Les connexions puja i baixa modelen les ordres que dna elcontrolador per pujar i baixar la barrera.

Les variables de temporitzaci t ... se les suposa globals a tots els processos isn inicialitzades amb les restriccions

taproximaci > tbaixada i tlluny > tpuja

30

Soluci

Controladortbaixar:= taproximaci - tbaixada

* trenentradelay(tbaixar)[]baixatrensurt[]puja

Problema 2.5Un procs emissor Em envia un missatge a un procs receptor Re per la con-nexi c, de tipus Missatge. A continuaci, Em espera un reconeixement per laconnexi ack de tipus Nul durant tout unitats de temps. Quan expira aquesttemps torna a enviar el mateix missatge. Quan rep el missatge de Em, Re li en-via un missatge de reconeixement per ack, per amb probabilitat pack. Quan noli envia, simplement no fa res. Els dos processos buclen per sempre en aquestesactivitats. Completeu el diagrama

| |Em

ve:= nou_missatgeCompleteu. . .

ReCompleteu. . .

a fi que modeli els dos processos descrits. Suposeu declarades les connexions iles variables locals ve, local a Em, i vr, local a Re, de tipus missatge. Suposeutamb disponible el procediment boole randT(p), el qual retorna cert amb pro-babilitat p. La sentncia ve:= nou_missatge posa un nou missatge a ve. Podeutornar-la a usar si cal.

Problema 2.6Completeu el model del protocol de parada i espera de la Secci 2.4. Concreta-ment heu de modelar el receptor i el canal de retorn segons les indicacions delapartat Els altres procediments de la Secci 2.4. Heu de fer un procedimentper a cada un dels dos processos. Feu-los de manera que les operacions de co-municaci quedin acoblades amb les que ja existeixen dins dels procedimentsexplicats en la secci.

Problema 2.7Doneu el procediment modular receptor. El seu comportament ha de ser elsegent: quan no est tractant cap missatge, ha destar atent a rebre missatgesdels processos P1, P2 i P3 que poden enviar-li contnuament per les connexionsdeP1, deP2 i deP3, respectivament, de tipus Missatge. Tot missatge rebut ha deser tractat en funci del ve que li ha passat. Suposeu fet i useu el procedimentr:=tracta(m,vei) per tractar el missatge m, de tipus Missatge rebut del ve , detipus 1..3. La variable r, de tipus RTract, guarda el resultat del tractament, el

31

qual ha de ser enviat, per la connexi aCol de tipus RTract, a un procs collectorabans dacceptar cap nou missatge. Tots els processos esmentats estan connec-tats en parallel.

Problema 2.8En lesquema,

con

c1,c2,endInf1,endInf2:nulinf1,inf2:Integer

| |E

var

v:Integer*

| |

[]c1 []c2completeu. . .

usem la informaci rebuda a vcompleteu. . .

P1var

val1:Integer*

val1:=nova informacicompleteu. . .

P2var

val2:Integer*

val2:=nova informacino cal que completeu.. . .

un procs E demana cclicament a dos vens en parallel, P1 i P2, que li passininformaci. Ho fa per les connexions c1 i c2. A continuaci, espera la primeraresposta (solament una), de P1 o de P2, per les connexions inf1 o inf2 respec-tivament. La deixa a la variable . Les connexions endInf1 i endInf2 serveixenperqu E indiqui a P1 o a P2, respectivament, que E ja ha agafat una resposta.Completeu les parts indicades de lesquema anterior de manera que, complinttot lanterior, cap procs pugui quedar aturat indefinidament.

32

3 Sistemes amb memria compartida

3.1 Motivaci

El tema daquest captol s daplicaci a forces camps dins el disseny i desenvolu-pament de sistemes generals, encara que el seu marc de fons siguin els multipro-cessadors amb memria compartida. El tema sanomenava programaci concur-rent quan lescenari era un sistema monoprocessador. Sha anat generalitzant,amb el temps, a multiprocessadors i altres sistemes.

Un escenari real daplicaci est format per programes mquina accedint a me-mries compartides i corrent sobre processadors diferents. Es treballar ambmodels daquesta realitat. El tractament s aplicable, amb alguna extensi, asistemes distributs, sense memria compartida. Sexposa en una secci daquestcaptol. En tota situaci on es programa en llenguatges dalt nivell, hi ha uncompilador i un assemblador que els tradueixen a codi mquina seqencial. Elsistema operatiu sobre el qual corren aquests tamb est format per instruccionsmquina. Sest tamb en un escenari de programes dinstruccions mquinacorrent sobre multiprocessadors, amb memria compartida.

La problemtica tractada aqu, i les solucions, sn adients per a molts camps:sistemes monoprocessador i multitasca, programaci sobre computadors multi-processador, modelat i disseny de hardware digital, sistemes operatius, xarxesde comunicaci, etc. Si esteu treballant en algun daquests temes, amb tecnolo-gies concretes, podreu fer el pont mental entre les vostres situacions reals i elnivell de modelat en qu el captol treballa; i amb el qual tindreu un mtodedanlisi precs dels vostres sistemes. Revisem aquestes rees:

1. Sistemes monoprocessador i multitasca. En ells el sistema operatiumultiplexa un sol processador entre ms duna tasca daplicaci. Exemplesdaquestes tasques sn els processos i els threads dels sistemes operatiusactuals. Les tasques sn modelades com processos composats en parallel,els quals tenen accs a variables a memria compartida, corrent totes en elmateix processador.

2. Programaci sobre computadors multiprocessador. Aqu es t msdun processador, que pot accedir a la memria compartida entre ells. Cadaprocessador pot fer crrer tasques sobre un sistema operatiu. El sistema pottenir memries cau, les quals sn transparents. Com en lescenari anterior,aquest segon escenari es modela amb processos parallels amb variablescompartides entre ells.

3. Modelat i disseny de hardware digital. En la major part de dissenystenim registres i altres recursos hardware, els quals han de ser accedits perles diverses parts del circuit. Per exemple, el disseny electrnic dalt nivell,on un sistema electrnic s vist com un conjunt de processos o subsistemesque treballen en paral.lel. Com exemple daquest escenari tenim el mode-lat de planificadors de processadors superescalars, el qual es pot fer ambprocessos parallels accedint a lestat de planificaci mantingut a variablescompartides.

33

4. Sistemes operatius. De fet, lanlisi rigors de processos parallels ambmemria compartida, la concurrncia, va ser iniciat amb lobjectiu de dis-senyar i organitzar elegantment els sistemes operatius multitasca i mono-processador, per fer-los de funcionament clar i segur.

5. Xarxes de comunicaci. Per modelar-les s molt adient i prctic ferservir variables a memria compartida, a ms de connexions.

6. Altres. Sistemes de telecontrol en temps real, sistemes de bases dedades, protocols de telecomunicaci, etc.

A fi de reduir lesfor, en aquest captol es tracta la problemtica comuna atotes les aplicacions esmentades. Es fa de forma simplificada o abstracte, elqual vol dir eliminar molts dels detalls que sn especfics a cada una delles. Esposa especial mfasi en la verificaci. Amb aquest fi, el funcionament es defineixamb propietats expressades en lgica de predicats i es demostra si el model lessatisf, o no. Es treballa sobre una mquina de transicions finites (MTF), la quals associada sistemticament al model.

3.2 Suposicions de base i validaci de models

Introducci

A fi de poder analitzar i raonar amb un cert rigor sobre tots els sistemes en-globats a la programaci concurrent, s necessari fixar una srie dhiptesis decomportament dels programes concurrents. A aquest conjunt se lanomena Mo-del Abstracte de la Programaci Concurrent, o ms senzillament, Abstracci dela Programaci Concurrent. Aquest model representa una forma dinterpretar laconstrucci de paral.lelisme vista en el captol anterior. Un conjunt de processosconnectats en paral.lel P1, P2, ... ,PN, els quals poden accedir a variables globals,com mostra la figura 3.1..

VARVariables compartides.

v1, v2, ... ,vmProcessos en paral.lel.

| |P1Primer process.. . .

P2Segon process.. . .

... PNN-esim process.. . .

Figura 3.1.: Processos parallels amb variables compartides

Per poder dur a terme lexecuci dels processos hi hauran processadors, al menys,un. Lordre temporal dexecuci de les parts dels processos lanomenarem cal-endari dexecuci (schedule). La part del sistema que determina el calendari

34

P2P1

n

M

r1 r2

Arq1 rq2

ack1 ack2

sel

Figura 3.2.: Dos processadors amb memria compartida i rbitre

lanomenarem planicador temporal (scheduler). La figura 3.2. representa unhardware real amb dos processadors.

Suposarem que els processadors accedeixen a un bus, el de la memria compar-tida, M. Aquest bus tindr un protocol daccs basat en un rbitre del bus, A. Totprocessador ha de demanar perms a lrbitre quan vol usar el bus. Lrbitre sun circuit que solament deixar usar el bus a un processador en cada cicle. Elsaltres hauran desperar. Per tant, si dos processadors volen dur a terme simult-niament una operaci sobre la memria compartida, per exemple els dos volenfer una crrega (instrucci LOAD), lrbitre deixar fer-ho noms a un. Quan hagiacabat el primer, llavors deixar fer la crrega al segon. Igualment ocorrer ambinstruccions demmagatzemament (STORE).

Lrbitre s, de fet, un planificador, a un primer nivell, ja que determina lordredexecuci. La programaci concurrent pretn estudiar propietats que valen pera qualsevol calendari concret dexecuci, resultat de lactuaci de lrbitre. Comhem dit, lrbitre tan sols posa limitacions relatives a ls del bus de memria.Suposarem que lexecuci doperacions sobre memria dels processadors podrseguir qualsevol ordenaci possible, compatible amb les limitacions imposadesper lrbitre. A aix en direm model dentrellaament doperacions atmiques.

Com a conseqncia, labstracci de la programaci concurrent que estudiaremconsisteix en els principis segents: atomicitat, seqencialitat, entrellaa-ment, no-determinisme. Els quals sn exposats a continuaci.

35

Suposicions i nocions de base

Atomicitat

Els processos estan formats per parts, lexecuci de les quals s indi-visible. Per exemple, lexecuci de les instruccions dels processadors s indivisi-ble. Per tant, les considerarem operacions atmiques. Aix val especialment pera les instruccions daccess a memria, tant LOADs com STOREs.

En general, al considerar processos concurrents i haver de raonar sobre ellssempre hem de definir quines sn les seves parts indivisibles. Per deduir qual-sevol propietat hem de tenir ben clar on s latomicitat, o quina atomicitat estemsuposant. Altrament, s impossible raonar.

Exemple

Suposem un procs que incrementa la posici n de memria:

n := n + 1,

La seqncia doperacions atmiques ser, per exemple:

LOAD r1 nADDI r1 1STORE r1 n,

Les operacions atmiques reals sn les tres instruccions mquina.

Atomicitat en la realitat

Correspon a les instruccions mquina. Sexecuten sense divisi, per cons-trucci del hardware. No cal considerar parts de lexecuci de les instruccions,doncs cap procs pot veure els canvis interns al final daquestes parts.

Atomicitat en el model

Sovint s cmode suposar que les sentncies del model sexecuten atmi-cament. Aix fa ms senzills els raonaments. En lexemple, la sentncia n :=n + 1 seria considerada sense parts. No obstant, haurem de justificar aquestasuposici, la qual no sempre correspon a la realitat.

Seqencialitat

Una vegada escollida latomicitat, suposarem tamb que lexecuci dun procssobre un processador equival a una seqncia doperacions atmiques,les instruccions en lexemple esmentat abans. De fet, aix correspon al que jasabem de programaci imperativa i seqencial.

36

Exemple

En lexemple anterior, el procs executa una seqncia doperacions atmiques,les tres instruccions mquina o la sentncia n := n+ 1, depn del nivell datomi-citat que considerem (real, model). En lltim cas, tindrem una seqncia delongitud dun sol tom.

Entrellaament

Lexecuci dun sistema de processos concurrents (paral.lels) ser vistacom una seqncia obtinguda entrellaant les parts atmiques de cadaprocs. Ser, doncs, un entrellaament de les operacions atmiques. Aix s,respectant lordre relatiu entre les operacions atmiques dun mateix procs.

Exemple

El diagrama de la figura 3.3. representa dos processos com lanterior, connec-tats en paral.lel:

Paral.lelisme Simple.VAR

n: integern:= 0| |

P1VAR

r1: integern:= n + 1

LOAD r1 nADDI r1 1STORE r1 n

P2VAR

r2: integern:= n + 1

LOAD r2 nADDI r2 1STORE r2 n

Figura 3.3.: Model de dues sentncies en parallel

Shan posat com a refinament de les sentncies les instruccions mquina corres-ponents. El segent entrellaament s fruit dalternar les instruccions dels dosprocessos.

LOAD r1 n+ 1 LOAD r2 n+ 2 ADD r1 1+ 3 ADD r2 1+ 4 STORE r1 n+ 5 STORE r2 n

Si suposem atomicitat a nivell de sentncia del model, llavors solament hi ha dosentrellaaments possibles, segons comenci primer P1 o no.

37

No-determinisme

Lentrellaament de les parts atmiques de cada procs concurrent sarbitrari, no est determinat. s no-determinista. Qualsevol ordre relatiu de lesoperacions atmiques de cada procs s vlid sempre que respecti lordre se-qencial de les operacions de cada procs. Les propietats i solucions que veuremhauran de funcionar o valdre per a tots els entrellaaments possibles. Maiparlarem dun scheduler o dun pla temporal, o entrellaament, concret. Aix, elsraonaments valdran per a tots els possibles planificadors.

Exemple

Continuant amb lexemple dabans, suposem ara lexecuci concurrent de dosprocessos iguals que lanterior, on n s a memria compartida i el seu valorinicial s 0. Si suposem atomicitat a nivell dinstrucci mquina, no tots els en-trellaaments possibles acaben amb el mateix valor de n a memria compartida.Si lentrellaament s: una instrucci de P1 seguida duna instrucci de P2, i aixsuccessivament, com ms amunt, el valor final de n s 1. En canvi, si primer esduu a terme tot el procs de lesquerra, seguit, i quan ha acabat es duu a termetot el de la dreta, el valor final de n s 2.

Zones crtiques

En lexemple anterior, lindeterminaci del valor final s deguda a que dos pro-cessos actualitzen independentment la mateixa posici de la memria comparti-da, n. Lindeterminaci del valor del resultat, naturalment, no s desitjada. El quevolem s que tots els increments siguin comptats. Per tant, el resultat correcte,en lexemple dels dos processos anteriors, seria 2. La soluci passaria per feractuar un procs desprs de laltre. Com ho farem?

Ms endavant introduirem primitives de sincronitzaci per solucionar el problema.De moment donem nom a la situaci problemtica: dos processos escriuen sobrela mateixa variable. Aquest accs concurrent s perills i en direm zona crtica.

Una zona crtica s la part del procs parallel (concurrent) que accedeixa una variable que altres processos concurrents tamb hi accedeixen.On, al menys, un procs escriu o modifica la variable compartida.

En lexemple, la sentncia n := n+1 s la zona crtica, amb les instruccions en lesque es descompon.

Si tots llegeixen no hi ha cap problema, el resultat no depn, llavors, delordre relatiu de lectures.

Shauran didentificar les zones crtiques dels processos concurrents i fer que maiexecutin instruccions entrellaades de les seves zones crtiques. O sigui, shaurdeliminar la possibilitat dexecuci daquells entrellaaments que duen a resul-tats indesitjats. Aix es tradueix en el fet que els processos executin la zona crti-ca un desprs de laltre, seqencialitat entre zones crtiques. Solament un procspot estar en un moment donat dins la zona crtica. Com que no permetrem certsentrellaaments estarem restringint lordre dexecuci. En realitat, estarem cre-ant un altre planificador, per damunt de lrbitre de bus. Ja ho anirem veient iconcretant.

38

Recursos

La problemtica vista fins aqu sobre lexemple duna variable compartida esdna en moltes altres situacions. Per aix, parlarem de recurs en comptes devariable, per referir-nos a tots els casos.

Generalitzant, una zona crtica s tota part de programa que accedeix a un recursque altres programes, concurrents amb ell, tamb poden accedir-hi, modificant-lo. No solament una variable compartida s un recurs. Per exemple, laccsa un disc s una zona crtica quan ms dun procs vol escriure-hi. Un discs tamb un recurs. Laccs a una impressora, tamb: no s desitjable quesurtin entrellaats els llistats produts per dos programes concurrents. Hem defer escriure primer a un i desprs a laltre. Limpressora s vista com a recurs.Una pgina de memria s un recurs, molts processos o tasques daplicacidemanen pgines al sistema operatiu, per escriure-hi.

En el cas del hardware, un bus s un recurs, solament un processador pot usar-loen tot instant. Un registre que pot ser llegit o modificat per diverses parts dunsistema electrnic digital, tamb s un recurs.

Amb la informaci vista fins aqu, es pot dir que la programaci concurrent donarmecanismes (algorismes) per a la gesti de recursos demanats per un conjunt deprocessos paral.lels; i tamb mtodes per verificar que les solucions satisfan unescertes propietats. Quines? Com? Es veur ms endavant.

Validaci de models

Un model sempre s una simplificaci de la realitat. Per tant, abans de raonarsobre un model, un sha de preguntar si el que vol resoldre o estudiar en el sis-tema real tamb t lloc en el model. En altres paraules, s vlid suposar atomici-tat a nivell de sentncia del model? Tenim dos nivells: el model, sobre el qual serms fcil raonar, i el sistema real. Lesquema segent mostra aquests nivells.

Model expressat en PADD. Els toms sn les sentncies.

Sistema real. Els toms sn les instruccions mquina.

Les solucions i les propietats seran formulades sobre el model. Naturalment,interessa que valguin tamb pel sistema real. La simplificaci del sistema realque el model sempre fa (les sentncies sn atmiques), no ha de ser tan burdaque elimini el problema que es vol analitzar i resoldre sobre el model.

En lexemple dabans, el model sempre compta b per el sistema real no. Es dirque el model no s vlid per raonar. Sha de recordar que tot raonament es f su-posant labstracci, o suposicions de base, de la programaci concurrent (atomi-citat, seqencialitat, entrellaament i no-determinisme) on latomicitat suposadas fonamental. Latomicitat a nivell de sentncia del model elimina artificialmentel problema.

39

Partici del conjunt de traces i classes dequivalncia

Una traa equival a un entrellaament. Observem que pot haver-hi ms dunentrellaament amb el mateix resultat final. Per exemple, si en un entrellaamentmovem una instrucci que no faci referncia a la memria compartida, semprerespectant lordre relatiu de les instruccions del seu procs, tindrem el mateixresultat final. En lexemple anterior, lentrellaament:

LOAD r1 n+ 1 ADD r1 1+ 2 LOAD r2 n+ 3 ADD r2 1+ 4 STORE r1 n+ 5 STORE r2 n

s el resultat de permutar la segona ( + 1) i la tercera ( + 2) instruccions de latraa alternant all que hem vist ms amunt. El seu resultat final s el mateixque abans: n = 1.

Quan canviar el resultat final? Solament pot canviar, i no sempre, quan es canvialordre de lectures (LOADs) i escriptures (STOREs) de processos diferents, doncsla seqncia determinada per les instruccions dun mateix procs no pot canviarmai. Tamb si es canvia lordre descriptures de processos diferents. Per exemple,lentrellaament:

LOAD r1 n+ 1 ADD r1 1+ 2 STORE r1 n+ 3 LOAD r2 n+ 4 ADD r2 1+ 5 STORE r2 n

canvia el resultat a 2. Si intercanviem lordre de la tercera instrucci (STORE) i laquarta (LOAD), queda lentrellaament:

LOAD r1 n+ 1 ADD r1 1+ 2 LOAD r2 n+ 3 STORE r1 n+ 4 ADD r2 1+ 5 STORE r2 n

el resultat torna a ser 1. Per tant, com a regla general, el resultat solamentpot canviar entre dos entrellaaments solament quan tenen ordenaments dife-rents dinstruccions de lectura i escriptura, o descriptures a la mateixa variablea memria compartida.

El conjunt de totes les traces pot ser partit en subconjunts disjunts(classes). Totes les traces de la mateixa classe donen el mateix resultatfinal. Les traces de classes diferents donen resultats diferents.

40

R