Systemes Distribues

Systmes Distribus
Communication de groupes Protocoles de diffusion Appels de procdures Mmoire Distribue- Modles de Cohrence
Boulekhmir Abdessamed
Systmes Distribus
Systmes Distribus
Table des matires :

Introduction Partie I : Communication de groupe Partie II : Protocoles de diffusion Partie III : Appel de procdures Partie IV : Mmoire partage Conclusion
2|Page
Systmes Distribus
Systmes Distribus
Introduction
Quest ce quun systme distribu ?
Un systme informatique distribu est une collection de postes ou calculateurs autonomes qui sont connects l'aide d'un rseau de communication. Chaque poste excute des composantes, par exemple des squences de calculs, issues du dcoupage d'un projet de calcul global, et utilise un intergiciel, qui s'occupe d'activer les composantes et de coordonner leurs activits de telle sorte qu'un utilisateur peroive le systme comme un unique systme intgr. Une proprit importante des systmes distribus est que la distribution est gnralement cache pour lutilisateur et les programmeurs de lapplication. Il prfre voir l'ensemble comme un seul et unique systme et ainsi cacher la complexit de la distribution le plus possible et augmenter la transparence du systme distribu. Cela permet de dvelopper le plus possible les applications de la mme faon que les systmes centraliss. Un systme distribu est gnralement sparable en plusieurs composantes entirement autonomes. Il nexiste pas de composante matre qui gre les autres et chacune est donc responsable de son propre fonctionnement. Cela permet, entre autres, davoir une htrognit dans la technologie utilise pour chaque composante, ils peuvent tre crits dans diffrents langages de programmation (Java, Cobol, C++, etc.) et s'excuter sur diffrents systmes d'exploitation (Mac OS X, Linux, Windows, etc.). Lautonomie des composantes fait que les systmes sont excuts simultanment (programmation concurrente). De plus, contrairement au systme centralis, les systmes distribus possdent plusieurs points de dfaillances (problme de composantes, rseau, trafics, etc.).
3|Page
Systmes Distribus
Systmes Distribus
I- Communication de groupes :
I.1- Quest ce quun groupe : Un groupe est un ensemble de processus formant une entit unique. Un message envoy ce groupe sera reu par tous les membres du groupe au mme moment. Un groupe est un ensemble de processus qui travaille ensemble. Un groupe comporte des processus qui agissent ensemble pour les besoins du systme ou de l'utilisateur.
I.2- Communication inter-groupe : I.1.1- Communication one-to-many: Est une mthode de diffusion de l'information d'un metteur (source unique) vers un groupe (plusieurs supports/medias). On lappelle aussi diffusion multipoint, multicast ou bien encore diffusion de groupe. Ainsi cest un moyen de denvoyer un message plusieurs destinataires, sans pour autant surcharger le rseau. Dans un rseau qui supporte le multicast, le message envoy plusieurs membres du rseau nest envoy quune seule fois. Cela est beaucoup moins consommateur en bande passante. Cette mthode est employe dans le domaine de la vido en demande, qui ncessite beaucoup de bande passante. Les utilisateurs sinscrivent un groupe et reoivent le flux en multicast.
I.1.2- Communication many-to-one: Many-to-one est une mthode de diffusion de l'information de plusieurs metteurs vers une seule destination.
4|Page
Systmes Distribus
Systmes Distribus
On distingue deux types de rception : Rception slective : le serveur reoit le message envoy par un client bien prcis. Rception non slective : le serveur ne peut slectionnait lmetteur des messages.
I.1.3- Communication many-to-many: Dans ce type de communication, on a plusieurs sources qui communiquent avec plusieurs destinations.
I.1- La synchronisation dans les systmes rpartis : Nous avons vu comment les processus communiquent dans un systme rparti. La communication entre processus est importante, mais il faut voir aussi : Comment ils cooprent. Comment ils se synchronisent les uns les autres.
5|Page
Systmes Distribus
II- Les protocoles de diffusion :
Systmes Distribus
Dans un systme centralis, les problmes de synchronisation sont rsolus par des smaphores : Rgions critiques. Exclusion mutuelle. Dans les systmes rpartis, le fait quil ny ait pas de mmoire partag, les smaphores (variables partages) ne peuvent pas exister.
I.1.2- Ordre stricte: Lordre de rception des messages doit tre le mme que celui dmission . ! Problme de synchronisation des horloges. La solution serait davoir une estampie. Si on suppose que les horloges des processus sont synchronises il suffit dinclure la date dmission comme identifiant.
15h10
16h01
I.1.2- Ordre consistant: Permet la rception des messages qui assurent la consistance des oprations. Remarque : Lordre absolu est un ordre consistant + lordre de rception doit tre le mme que celui de lmission.
Systmes Distribus
6|Page
Systmes Distribus
Afin davoir cet ordre deux solutions sont proposes : Solution 1 : many-to-one puis one-to-many (Centraliser)
Donner des numros de squences aux messages
Solution 2 : Protocole ABCAST (Dcentraliser)

L'algorithme ABCAST dcrit ici a t propos par Birman (1987) pour permettre une dlivrance uniforme sur tous les sites (c'est--dire dans le mme ordre sur tous les sites) de tous les messages envoys un groupe (ouvert ou ferm). Il utilise un mcanisme d'estampillage scalaire. Il s'agit d'un protocole de validation deux phases. Chaque membre du groupe dispose d'une horloge logique et gre une file d'attente des messages diffuss au groupe et qu'il a reus et sont en attente pour tre dlivrs.
1- Lmetteur affecte un numro temporaire de squence a son message qui est suprieur a tout les numros des messages prcdents . 2- Ce Message va tre reu par un membre du groupe, Chaque membre du groupe va proposer un numro de squence au message. Fmax : Le Nombre de squence max attribu dans le groupe Pmax : Cest le nombre de squence max attribu par le membre rcepteur I : Numro didentification du membre rcepteur. N : Taille du groupe Max (Fmax, Pmax) + 1 + i/N Le message est renvoy a lmetteur. 3- Quand lmetteur reoit les numros de squence proposs de touts les membres, il slectionne le plus grand et le retransmet dans un Commit Message . 4- A la rception du commit message chaque membre attribue ce numro au message.
7|Page
Systmes Distribus
Systmes Distribus
Les messages avec ce Commit Sequence Number sont ordonns dans une file et dlivrs au processus destinataire.
I.1.2- Ordre Causal:

Un protocole dordre causal est un protocole qui assure que l es messages reus sur un mme site sont dlivrs en respectant les dpendances causales entre les vnements dmission de ces messages. Algorithme CBCAST : Problme Il s'agit ici de fournir un protocole de diffusion de messages un groupe garantissant une dlivrance des messages sur les diffrents dites respectant la relation de causalit entre les diffrentes diffusions. Dans l'exemple suivant, on considre un groupe contenant 4 composants et un ensemble de 4 diffusions de messages. Si les messages sont dlivrs ds leur arrive sur les sites, la relation de causalit entre les diffrentes diffusions est viole :
Les dpendances causales entre les diffrentes diffusions sont les suivantes :
la diffusion de m2 par le second site est postrieure la rception de m1 par ce site (et donc la diffusion de m1): une dlivrance causale suppose donc que m2 soit dlivr aprs m1 sur tous les sites; la diffusion de m4 par le troisime site suit la rception de m2 par ce site: une dlivrance causale impose donc que m4 soit dlivr aprs m2 sur tous les sites. Par ailleurs cette mme diffusion suit celle de m3 par ce mme site et donc, la dlivrance de m3 devra donc prcder celle de m4.
8|Page
Systmes Distribus
Systmes Distribus
Une diffusion causale suppose donc que sur chaque site les message soient dlivrs dans un ordre correspondant l'un des suivants (m3 peut tre dlivr dans l'une quelconque des positions vertes): m3 m1 m3 m2 m3 m4 L'ordre d'arrive sur les diffrents sites est quant lui le suivant (les messages en rouge violent l'ordre impos pour une dlivrance causale :

sur S1 : m1 m3 m2 m4 sur S2 : m1 m2 m4 m3 (m4 arrive trop tt); sur S3 : m3 m1 m2 m4 sur S4 : m3 m4 m2 m1: d'une part m4 arrive trop tt par rapport m1 et m2 et, d'autre part, m2 arrive trop tt par rapport m1.On peut noter au passage que le canal de communication entre S3 et S2 ne respecte pas la proprit FIFO (le message m4 y double le message m3).
Algorithme CBCAST Dans l'algorithme dcrit maintenant utilisable pour des diffusions dans des groupes ferms, une estampille vectorielle (de taille n gale au nombre de membres du groupe) est utilise pour dater les diffusions :
A la rception d'un message, il est possible en comparant la valeur de l'horloge locale et l'estampille attribue par le message de savoir si le site rcepteur a reu tous les messages qu'il est cens avoir reus: pour que le message puisse tre dlivr, il faut que a. l'ordre FIFO soit respect sur le canal de l'metteur; b. le site rcepteur a reu des autres sites autant de messages que le site metteur en avait reus lors de la diffusion du message.
9|Page
Systmes Distribus
Systmes Distribus
En d'autres termes, un message est dlivr si et seulement si :
La dlivrance d'un message qui, lors de son arrive sur un site, ne satisfait pas au moins l'une des conditions prcdentes doit tre diffre sur ce site jusqu' ce que les deux conditions soient effectivement satisfaites. La mise jour de l'horloge locale est ralise lors de la dlivrance du message.
Exemple :
La figure suivante illustre l'utilisation de l'algorithme pour dtecter les arrives prmatures de messages et en diffrer la dlivrance :
les anomalies y sont repres en rouge (point A, B et C) ainsi que les valeurs courantes des horloges des sites qui y sont compares avec les valeurs des estampilles (vertes) des messages arrivant correspondant aux horloges des sites metteurs; pour les arrives de messages pouvant donner lieu une dlivrance du message, les valeurs courantes des horloges du site avant et aprs dlivrance sont respectivement en bleu (en haut) et en vert (en bas); les flches bleues indiquent les instants ou les messages pourront tre effectivement dlivrs.
10 | P a g e
Systmes Distribus
Systmes Distribus
III- REMOTE PROCEDURE CALL RPC:

Le modle Client-Serveur est un modle simple utiliser pour la structuration des systmes rpartis. Mais ce modle sappuie sur des communications de type entre/sortie (SEND / RECEIVE). Ce nest pas le modle plus efficace pour les systmes rpartis car son bu t est de rendre le comportement des systmes rpartis identique celui des systmes centraliss. III.1- Objectif de RPC: Appel aux procdures distantes presque aussi facilement quun appel aux procdures locales. III.2- Fonctionnement dun appel procdure (machine unique):
Count = read ( fd, buf, nbytes) ; fd = entier. Buf = Tableau de caractres. Nbytes = entier. 1. Lorsque le programme principal appelle la procdure read les paramtres dans la pile. 2. Lorsque la procdure read a termin son traitement, elle : Place le rsultat dans un registre. Efface ladresse de retour. Rend la main lappelant. 3. Lappelant enlve les paramtres de la pile pour retourner son tat original. Les paramtres peuvent tre passs : Systmes Distribus
il place
Par valeur. Par rfrence. Par Copy / restore.
11 | P a g e
Systmes Distribus
III.3- Fonctionnement du RPC:

On veut que lappel une procdure distante se fasse comme si lappel tait local. Mme si cela doit tre transparent pour lutilisateur, il est ncessaire que le mcanisme RPC mette en place des versions diffrentes pour lappel dune procdure selon quelle soit locale ou distante. On va donc avoir une souche client (client stub) et une souche serveur (server stub). Souche Client : La version cliente de la procdure est constitue dune souche cliente ( client stub ) qui est place dans la librairie locale. Lappel se fait ensuite comme avec une procdure locale (la pile est gre localement) et lexcution est prise en charge par le noyau. Par contre, les paramtres donne nest demande au noyau. ne sont pas stocks dans les registres et aucune
Les paramtres sont stocks dans un message construit par le noyau et envoy au serveur distant qui contient la partie serveur de la procdure. Le client attend ensuite que le serveur lui rponde. Souche Serveur : La version serveur de la procdure est constitue dune souche serveur et de la procdure. Lorsque le message parvient au serveur, le noyau passe le message la souche correspondante (qui est en attente de messages). La souche extrait les paramtres du message, renseigne la pile et appelle la procdure qui pense tre appele par un client local. Lorsque la procdure a termin son traitement, elle renseigne la pile et rend la main la souche (voir schma suivant). Systmes Distribus 12 | P a g e
Systmes Distribus
La cration des souches (stubs) est de la responsabilit du compilateur. la compilation les stubs sont crs et le compilateur peut saider dun langage de dfinition dinterfaces (IDL).
III.4- Le passage de paramtres:

Le passage de paramtres dans le cadre des RPCS nest pas forcment quelque chose de Simple. Dans les systmes rpartis, les machines peuvent tre diffrentes. Des problmes de conversion peuvent apparatre. La problmatique va donc tre de connatre le format du message et la plateforme cliente : Le premier octet (Byte) du message dtermine le format utilis par le client. Le serveur compare cet octet avec le sien : Si cest le mme aucune transformation nest ncessaire, sinon il effectue la transformation. Passage de pointeurs en paramtres Le pointeur (adresse) nest connu que dans lespace dadressage du processus qui le cre. Cette adresse nest valide que dans la machine o sexcute le processus. La souche client qui rcupre un pointeur, copie le contenu de la zone adresse dans le message. Au retour elle place le rsultat dans la zone.
III.5- Localisation du serveur:

La localisation dun serveur peut se faire de diffrentes manires : Statique : Code en dur ladresse du serveur dans le client. En cas de changement de ladresse, le client doit tre recompil (les programmes qui Accdent au serveur). Dynamique : lien dynamique (dynamic binding). Ce lien permet de faire dynamiquement connatre les clients et les serveurs. Le lien dynamique La construction du lien dynamique seffectue en plusieurs tapes. Dfinition de la spcification du serveur qui servira la gnration des souches. linitialisation, le serveur exporte son interface. Il lenvoie un binder (relieur) pour signaler son existence. Cest la phase denregistrement. Le serveur envoie ses informations : nom ; version identifiant (unique sur 32 bits en principe) ; Systmes Distribus
13 | P a g e
Systmes Distribus
handle (adresse IP, protocoles, etc.). Lorsquun Client appelle une procdure pour la premire fois : Il constate quil nest pas reli un serveur. Il envoie un message au relieur pour importer la version de la procdure quil d sire invoquer. Le relieur lui renvoie lidentifiant unique (ID) et le handle. Avantage : Cette mthode dimportation et exportation des interfaces est trs flexible. Les serveurs peuvent senregistrer ou se ds enregistrer. Le client fournit le nom de la procdure et la version et il reoit un ID unique et handle.
III.6- Les problmes lis aux RPCs dans les systmes rpartis:
1. Le client ne peut pas localiser le serveur. 2. Lappel du client narrive pas au serveur. 3. La rponse du serveur narrive pas au client. Il faut dissocier la panne avant lexcution de la requte ou aprs lexcution. Trois coles pour rsoudre ce problme : 1. Attendre que le serveur redmarre et relancer le traitement. Au moins un traitement est russi. (Peut-tre plus). 2. Abandon du client et rapport de lerreur. Au plus un traitement est russi. (Peut -tre aucun). 3. Ne rien dire au client (aucune garantie) Seuls avantages : Facile grer et implmenter. En rgle gnrale, crash du serveur = crash du client. Le client est en panne : Lorsquun client tombe en panne alors quil a demand un traitement un serveur, on dit que lchange devient orphelin. Cela a pour effet de gaspiller du temps CPU, de bloquer des ressources, lorsquil redmarre, il peut recevoir des messages antrieurs la panne (problme de confusion). Quatre solutions peuvent tre envisages : 1. Lextermination : Le client enregistre les appels dans un log. Au redmarrage lorphelin est dtruit. Beaucoup dcritures disque chaque RPC. Systmes Distribus
14 | P a g e
Systmes Distribus
2. La rincarnation : Le client tient compte du temps. Lorsquil redmarre, il annule les changes ente deux poques et reprend les changes orphelins. 3. La rincarnation lamiable : Comme prcdemment, avec en plus la vrification avec le serveur concern des changes orphelins. 4. Expiration du dlai : Un compteur de temps dtermine quand un change devient orphelin. Les orphelins sont dtruits. Un temps T dtermin identique pour tous est donn 1 RPC. Difficile de choisir un temps T (les RPCs sont sur des rseaux diffrents).
III.7- Les protocoles RPC:

Pour le protocole RPC un certain nombre de choix sont faire. III.7.1- Avec ou sans connexion Avec connexion Avantage : Simple utiliser. Pas dACK ncessaire. Pas de perte de paquets. Dsavantage : Trop difficile mettre en place sur un WAN. Trs pnalisant sur un LAN (performance pas bonne). Note : Les systmes rpartis utilisent des protocoles sans connexion III.7.1- Utilisation dun protocole standard ou dun protocole propritaire Systmes Distribus
Protocole propritaire = protocole conu pour les RPCs. Protocole standard (IP, TCP, UDP) Avantage : Dj construit. Implmentation effectue et disponible. Utilisable par tous les systmes (UNIX, Windows, etc.).
15 | P a g e
Systmes Distribus
Supporter par la majorit des rseaux. Dsavantage : Protocoles peu performants. Conus pour des connexions TCP. Protocole propritaires Avantage : Evite les checksums. Longueur de paquets variables. Adapt au systme (spcialis). Dsavantage : Beaucoup de travail de dveloppement. Difficile faire adopter par les autres (nouveau protocole).
III.8- Accus de rception :

Si une RPC doit tre dcoupe en plusieurs petits paquets. 4Ko de donnes envoyer
Choisir entre un accus de rception par paquet. Attente accus avant envoi suivant
16 | P a g e
Systmes Distribus
Systmes Distribus
Si un problme est rencontr sur un paquet le client le renvoie. Ou seul accus de rception la fin de lenvoi. Envoi aussi vite quil peut.
Si un problme est rencontr sur un paquet le serveur le redemande.
III.9- Le chemin critique:

Le code de la RPC est crucial pour les performances du systme. La squence dinstructions excutes pour chaque RPC est appele chemin critique. Cest le temps ncessaire et rajout par la RPC vs si le traitement tait effectu en local. Ce chemin critique dmarre quand le client appelle la souche client et se termine lorsque le rsultat est renvoy par le serveur.
17 | P a g e
Systmes Distribus
Systmes Distribus
Note : La question intressante ensuite est : Quelle est la partie du chemin critique o Lon passe le plus de temps. La rponse permet de savoir o leffort doptimisation doit tre fait.
III.10- Gestion du temps (timer):

Tous les protocoles sont bass sur des changes de messages sur les moyens de communication. Les messages peuvent tre perdus et crer de graves problmes dintgrit dans le systme. Un des moyens de pallier ce problme est la mise en place dun timer ( gestion du temps). Qui va associer un horodatage chacun des messages et dfinir une dure de vie (dlai dexpiration). Si le temps imparti pour la dure de vie dun message est coul, le message sera renvoy. Le nombre de renvois est dfini dans le protocole. Deux mthodes peuvent tre envisages : 1. Mise en place dune structure spcifique. 2. Insertion dun champ dans la table des processus. Mise en place dune structure spcifique Une structure va tre construite : Spcification de lexpiration. Quelles sont les actions prendre en cas dexpiration. La structure sera insre dans une liste existante (qui contient dautres structures). La liste doit tre surveille. La liste est trie par temps. Lorsquun message est envoy la liste est mise jour. Lorsquun accus de rception ou une rponse revient, lentre est retire de la table. Systmes Distribus Note : Parce que la plupart du temps les timers nont pas le temps dexpirer, on perd beaucoup de temps insrer puis effacer les entres non expires. Donc une autre approche peut tre envisage. Insertion dun champ dans la table des processus. Lide est de rajouter une entre expiration dans la table des processus. La mise jour des timers devient quelques instructions en langage machine. A intervalles rguliers (toutes les secondes) le noyau parcourt la table et compare les timers avec le temps courant.
18 | P a g e
Systmes Distribus
III.11- Quelques problmes lis aux RPCs:

a- Principe de transparence : Lintroduction dun mcanisme RPC dans un systme monoprocesseur ne doit pas : Gnrer un nouvel ensemble de rgles qui empche la construction dobjets qui tait possible avant. Impliquer lutilisation obligatoire dobjets optionnels auparavant. b- Problme des variables globales : Comment peut-on accder des variables globales partir de procdures distantes ? Les accs doivent tre construits. Le principe de transparence est donc viol. c- Problme des paramtres variables : Comment le passage de paramtres dont on ne connat pas la taille priori peut se faire ? (Par exemple les tableaux en langage C). Ide : On peut coder les longueurs en dur mais : Si taille des donnes < maxi : perte despace. Si taille des donnes > maxi : erreur.
19 | P a g e
Systmes Distribus
Systmes Distribus
IV- Mmoire partage : Introduction

En informatique, et dans le cadre de systmes multiprocesseurs, chaque processeur sa propre mmoire. Lorsque la mmoire est rpartie ou distribue les processeurs ou les applications de chaque nud peuvent utiliser un rseau pour accder aux donnes prsentes sur un autre nud. Ce rseau peut tre interne la machine et gr au niveau matriel (NUMA) ou externe un nud de calcul (Ferme de calcul), et partag au niveau logiciel (MPI).
IV.1 La mmoire partage et rpartie : Distributed and Shared memory (DSM). Implmentation facile: Une ou plusieurs copies de page en lecture seule possible. Une et une seule copie de page en criture. Par contre avoir une seule copie de page en criture gnre un goulet dtranglement. Il est impratif davoir plusieurs copies de page en lecture et en criture dans le systme. Cela peut conduire des problmes dincohrence. IV.1.1 Les modles de cohrence Les modles de cohrence sont des contrats bass sur des rgles. Ils permettent de grer plusieurs copies de pages mmoire dans des mmoires dans systmes rpartis. Lobjectif est dviter les goulets dtranglement associs lutilisation concurrente dune page mmoire unique. Il existe plusieurs modles (ou rgles) de cohrence : Cohrence stricte. Cohrence squentielle. Cohrence causale. PRAM (Pipelined RAM). Cohrence processeurs (faible, relche, par entre). Ces rgles de cohrence correspondent un contrat entre la mmoire et les programmes excuter dans le systme et vont assurer la cohrence des donnes utilises par les programmes, pour les lire ou les modifier (cest le souci des concepteurs et sur tout des utilisateurs). Systmes Distribus
20 | P a g e
Systmes Distribus
IV.1.1.1 La cohrence stricte La rgle de la cohrence stricte est la suivante : Toute lecture d'une position de mmoire x retourne la valeur stocke par l'criture la plus rcente. La problmatique x est stock sur une machine B. Un processus sur une machine A lit x un temps T1 (A envoie un message B pour obtenir x). A un temps T2 (un peu plus tard) avec T2 > T1, un processus de B modifie x. Si T2 T1 = 1 ou 2 nanosecondes, pour que A rcupre x avant que B ne lait modifi, linformation doit transiter une vitesse suprieure la vitesse de la lumire. Note : 10 fois la vitesse de la lumire si les machines sont trois mtres lune de lautre. Incohrence : A et B nont pas la mme valeur de x. Mais est-ce raisonnable quun contrat de cohrence stricte soit pass entre les logiciels et la mmoire ? Si des processus modifient lisent et crivent en mmoire des frquences approchant les nanosecondes cela est pratiquement (physiquement) impossible honorer. En conclusion, cette rgle est la plus contraignante, elle tient compte d'un temps global absolu, ainsi la dtermination de la plus rcente ne sera pas ambigu. Elle implique que lorsque la mmoire est base sur la cohrence stricte : Tous les processus voient instantanment toutes les critures qui y sont effectues. Lorsquune lecture est effectue, la dernire mise jour et fournie. Peu importe lorsque la prochaine criture se produira. IV.1.1.2 La cohrence squentielle La rgle de la cohrence squentielle est la suivante : Le rsultat de toute excution est identique une excution squentielle et ordonne de tous les processus, et les oprations de chaque processus apparaissent dans l'ordre d'excution de son programme. La problmatique au travers dun exemple Soit trois processus effectuant chacun deux oprations atomiques : P1 : o a = 1 ; o print (b,c) ; P2 : o b = 1 ; o print (a,c) ; P3 : o c = 1 ; o print (a,b) ;
21 | P a g e
Systmes Distribus
Systmes Distribus
Les trois processus sexcutent en parallle sur trois processeurs diffrents et ont tous accs aux variables a, b, c dans une mmoire rpartie et partage. Avec six instructions indpendantes on peut avoi r en thorie 6! (720) squences dinstructions diffrentes. Nanmoins, comme lordre dexcution a=1 et avant print(b,c) doit tre respect, cela ramne 90 squences possibles. Prenons quatre squences parmi ces 90 : Seq1 : a=1 ;print(b,c) ;b=1 ;print(a,c) ;c=1 ;print(a,c) ; o Res1=001011 Seq2 : a=1 ;b=1 ;print (a,c) ;print(b,c) ;c=1 ;print(a,b) ; o Res2=101011 Seq3 : b=1 ;c=1 ;print(a,b) ;print(a,c) ;a=1 ;print(b,c) ; o Res3=010111 Seq4 : a=1 ;b=1 ;c=1 ;print(b,c) ;print(a,c) ;print(a,b) ; o bvRes4=111111 Nous trouvons quatre rsultats diffrents en fonction de lordre de traitement des instructions. Ici la notion de temps a disparu, seul l'ordre d'excution compte. Pour pouvoir appliquer cette rgle de cohrence il faut s'assurer qu'avant le dmarrage d'une opration mmoire les autres oprations soient termines. Deux conditions doivent tre respectes : La squence dexcution : exemple prcdent. La cohrence mmoire : une lecture dans une localisation renvoie toujours la valeur dernirement mise jour. Note : Assez facile programmer, mais gros problme de performance. Car si le nombre de lectures augmente alors le nombre dcritures diminue : T = temps mini de transfert entre deux nuds. R = temps de lecture. Systmes Distribus W = temps dcriture. R+W T IV.1.1.3 La cohrence causale : Cette rgle est une version affaiblie de la rgle de cohrence squentielle, qui tient compte de la relation causale potentielle ou pas entre les vnements. La rgle stipule : Les critures qui ont potentiellement une relation causale doivent tre vus par tous les processus dans le mme ordre. Des critures parallles peuvent tre vus dans un ordre diffrent sur diffrentes machines.
22 | P a g e
Systmes Distribus
Un exemple : Soit P1 qui crit x. Soit P2 qui lit x et crit y. Potentiellement lcriture de y peut-tre la cause de x. En rsum : Si deux processus crivent simultanment deux variables, il sagit de processus concurrents qui nont pas de relation causale. Si un processus lit une variable et ensuite en crit une autre, alors il y a possibilit de relation causale. Exemple : P1 ------ E(x)1 --------------------------------------------------------------------P2 --------------- L(x)1 ----- E(x)2 ----------------------------------------------P3 ---------------------------------------- L(x)2-- L(x)1KO : P3 demande P2 puis P1 P4 ---------------------------------------- L(x)1-- L(x)2OK : P4 demande P1 puis P2 IV.1.1.4 La cohrence PRAM (Pipelined RAM) La rgle stipule : Les critures causales, faites par un processus, sont vues par tous les processus dans le mme ordre, les critures parallles (concurrentes) peuvent tre vus dans un ordre diffrent par des processus diffrents. 3.1.1.5 La cohrence processeur Note : Pratiquement identique la cohrence PRAM. La cohrence PRAM et processeur sont les mcanismes qui sont les plus performants. Elles sont moins restrictives pour les applications partant du principe que les applications nont forcment connatre tous les accs en criture qui sont effectus. Un moyen serait alors de rentrer les critures en section critique (personne ne peut accder aux variables) et denvoyer les modifications tout le monde lorsque les mises jour sont effectues. Cela introduit la notion de variables de synchronisation pour les modles de cohrence. Trois modles de cohrence sont dfinis pour la cohrence processeur : 1. La cohrence faible. 2. La cohrence relche.
23 | P a g e
Systmes Distribus
Systmes Distribus
3. La cohrence en entre. IV.1.1.5.1 La cohrence faible Cette rgle comprend trois articles : 1. Les accs aux variables de synchronisation ont une squence cohrente. Tout accs est diffus tous les nuds qui partagent la mmoire et aucun autre n'est possible. 2. L'accs une variable de synchronisation n'est pas autoris tant que toutes les critures qui prcdent ne sont pas excutes. (On vide le pipeline). 3. L'accs aux donnes (criture ou lecture) n'est pas autoris tant que tous les accs aux variables de synchronisation qui prcdent ne sont pas excuts. (En effectuant une synchro avant de lire la donne, on est sr davoir la bonne valeur). Pour viter la violation il faudrait retirer la lecture L(x)1 ce qui rendrait E(x)1 et E(x)2 concurrent et non plus causal. Copyright (C) 1997-2007. JM Rodriguez. Tous droits rservs. Reproduction interdite par tous moyens sauf des fins de citation. Une variable de synchronisation permet de synchroniser la mmoire. Lorsqu'une synchronisation est excute, la fin, les critures sont transmises aux autres machines, et les critures d'une autre machine sont rpercutes dans la machine. La synchronisation permet denvoyer toutes les critures que lon effectues et de recevoir celles des autres. Exemple de squences : Autorise P1---- E(x)1 --- E(x)2 --- Synchro -------------------------------------P2 -----------------------------------------L(x)1 --- L(x)2 --- Synchro P3 -----------------------------------------L(x)2 --- L(x)1 --- Synchro Non autorise P1---- E(x)1 --- E(x)2 --- Synchro -------------------------------------P2 ----------------------------------------Synchro -- L(x)1 (Devrait lire la valeur 2) IV.1.1.5.2 La cohrence faible Cette amlioration de la cohrence faible permet la mmoire de savoir quand elle entre ou quand elle quitte une rgion critique. Deux oprations compltent le dispositif : Acquisition (Acq), indique la mmoire qu'un entre dans la rgion critique est en cours. Systmes Distribus
24 | P a g e
Systmes Distribus
Libration (Rel), signale la mmoire la sortie de la rgion critique. Voici une squence valide. P1- Acq(L) - E(x)1 - E(x)2 - Res (L) -------------------------------P2 ---------------------------------------- Acq(L) --- L(x)2 --- Res (L) Lecture garantie P3 ---------------------------------------------------------------- L(x)1 Lecture non garantie La rgle se dfinit ainsi : 1. Avant un accs une variable partage, toutes les acquisitions prcdentes du processus ont t excutes compltement. 2. Avant qu'une libration soit autorise il faut que toutes les critures et lectures du processus soient excutes compltement. 3. Les oprations 'acquisition' et 'libration' doivent tre cohrentes avec le processeur. IV.1.1.5.3 La cohrence par entre La rgle s'tablit ainsi : 1. Un accs d'acquisition d'une variable de synchronisation n'est pas autoris pendant le droulement d'un processus tant que les donnes protges de ce dernier ne sont pas mises jour. 2. Pour qu'un processus accde en mode exclusif une variable de synchronisation, il faut s'assurer qu'aucun autre processus ne soit en train de travailler, mme en mode non-exclusif, avec cette variable de synchronisation. 3. Lorsqu'un accs, en mode exclusif, une variable de synchronisation est ralis, tout processus qui suit en mode non-exclusif et qui demande accs la variable de synchronisation doit demander au propritaire de la rgion critique les donnes disponibles. IV.1.1.6 Synthse des rgles de cohrence Le premier tableau pour la cohrence sans synchronisation et le suivant pour la cohrence avec synchronisation rsument les caractristiques majeures des diffrentes rgles de cohrence. Systmes Distribus 25 | P a g e
Systmes Distribus
Conclusion
26 | P a g e
Systmes Distribus

Systemes Distribues

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Systemes Distribues

Transféré par

Droits d'auteur :

Formats disponibles

Systmes Distribus

Table des matires :

II- Les protocoles de diffusion :

Donner des numros de squences aux messages

Solution 2 : Protocole ABCAST (Dcentraliser)

I.1.2- Ordre Causal:

En d'autres termes, un message est dlivr si et seulement si :

III- REMOTE PROCEDURE CALL RPC:

Par valeur. Par rfrence. Par Copy / restore.

III.3- Fonctionnement du RPC:

III.4- Le passage de paramtres:

III.5- Localisation du serveur:

III.7- Les protocoles RPC:

III.8- Accus de rception :

Si un problme est rencontr sur un paquet le serveur le redemande.

III.9- Le chemin critique:

III.10- Gestion du temps (timer):

III.11- Quelques problmes lis aux RPCs:

IV- Mmoire partage : Introduction

Vous aimerez peut-être aussi