Algorithmes de mise en œuvre des systèmes répartis

Systèmes Distribués

Techniques et Algorithmes de mise en œuvre des systèmes répartis

Algorithmes de mise en œuvre des systèmes répartis

1. GENERALITES

ν ν

S S y y s s t t è è m m e e s s r r é é p p a a r r t t i i s s : : R R é é s s e e a a u u

ν ν

M M a a ch c hi i n n e e s s , , p p e e r r s s on o nn ne es s , , p p r r oc o ce e s s s s u u s s , , « « ag a g e e n n t t s s » » … … l l oc o ca al li i s s é é s s à à de d es s e e n n d d r r o o i i t t s s d d i i f f f f é é r r e e n n t t s s . .

réseau

ν ν LeLess pprroocecesssususs cocoooppèèrreenntt ppoouurr rérégglleerr unun prproobbllèèmmee ununiiqquuee.. PaParr écéchhaangngee ddee memessssaaggeess

FaFaiibblleemmeenntt cocouuppllééss sosouuvvenentt aasysynncchhroronnee

DDélélaaiiss aarrbbiittrraaiirreess

ppaass dd ’h’hoorrllooggee gglloobbaallee

ν ν OOppttiimmiissaattiioonn ddeess ttââcchheess ((ssiitteess ssppéécciiaalliissééss)),, rrééssiissttaannccee aauuxx ppaannnneess ...

ν

ν DiDissttriribbuuttiioon n d’d’unun ccaallccuull..

message de contrôle

• L ’observation n ’est possible que par le biais de messages de contrôle (avec des temps de transmission arbitraires).

• Les processus ne peuvent être observés simultanément.

• Pas d ’horloge globale.

• suivi d ’un calcul ?

ν ν ExExeemmplplee dede prproobbllèèmme e : : l’l’obobsseerrvvaattioion n d’d’unun ccaallccuull didissttrriibbuuéé

Compte A : 4500

Compte A : 0

• Pas de vision globale.

• Pas de temps commun.

• Combien a-t-il d ’argent ?

ν ν ExExeemmplplee : : InIntteerrcoconnnneexxiioon n babannccaaiirere ::

ν

ν AuAuttrree exexememplplee : : l’l’eexxccllususioion n mumuttuueellllee..

νν CaCass cecennttrraalliissé é : :

ν ν LaLa clcleeff eesstt ununee vvaarriiaabbllee cocommmmununee ((vvererrroouu))..

νν CaCass didissttriribbuuéé : :

ν ν ToTousus lleess écéchhaannggeess d’d’ininffoormrmaattiioon n sese fofonntt ppaarr memessssagageess. .

vert

rouge

rouge Observateur 1

Observateur 22

sync mess comportement autonome

vert

temps

Dans quelle mesure cette observation est fausse ?

• Chaque feu passe au rouge de façon autonome.

• Un feu ne passe au vert que si l ’autre est rouge.

• Les temps de transfert sont arbitraires.

Cohérence temporelle :

(m2,A)

B

C

(m3,B)

∆t

• C peut voir (m1,A) avant ou après (m3,B).

• Peut influer sur le déterminisme de l ’algorithme global ! A

(m1,A)

• A envoi un message à C puis à B

• B réagit en envoyant un message à C.

Résumé :

♦ Distribution :

Partage (donnée ressources)

Synchronisation + Communication Compétition

Coopération (programme) Coordination

: Sans mémoire commune.

: Sans horloge globale.

Ce qui est distribué et les problèmes associés :

1) Distribution des données : duplication et/ou partitionnement - problème de cohérence des données à un instant.

- problème d’accès (exclusion mutuelle répartie).

- problème de définition optimale des répartitions.

2) Distribution des calculs :

- problème de blocage « inter-blocage ».

- problème de terminaison d’un calcul.

- de coordination (rendez-vous).

3) Distribution des algorithmes de mise en œuvre de la distribution - gestion de l’exclusion mutuelle sans mémoire commune.

- gestion de la cohérence des données dans le temps.

- détection de la terminaison et de l’interblocage.

♦ L’algorithmique distribuée :

• Eléments de base : processus ou sites et voies de communication

Processus 1

Processus 2

Processus 3

♦ Voies de communication (ou liaison, ou canaux)

• Structures :

• Arbre : chaque processus communique avec ses fils et son père

• Maillage complet : chaque processus communique avec tous les processus

Attention : Ne pas confondre la structure du réseau local avec la structure de communication de l’algorithme distribué.

• Anneau : chaque processus

communique avec ces deux voisins .

• Etoile : un processus particulier peut communiquer avec tous les autres (hiérarchie).

♦ Voies de communication :

• Propriétés comportementales : Hypothèses de simplification classiques

• H1 : La transmission sur la voie se fait sans duplication de message.

• H2 : La transmission se fait sans altération des messages.

• H3 : Pour tout couple de processus communicants, l’ordre de réception des messages est identique à leur ordre d’émission Æ pas de déséquencement.

• H4 : Le délai d’acheminement des messages est fini (bien qu’aléatoire) Æ pas de perte.

• H5 : Le délai d’acheminement est borné.

♦ Processus :

• Programme séquentiel, instructions classiques (tanque faire, pour tout ….)

• Réceptifs à des événements (A la réception de « message » faire : …)

• Emetteurs d’événements (envoyer(« message »)).

• Choix non déterministes : si deux événements arrivent en même temps.

• Il existe des langages dédiés : CSP, ADA, PDIL

♦ Processus : degrès de répartition, niveau de symétrie :

• non symétrie : Texte différent pour chaque processus (client-serveur)

• symétrie de texte : Même texte, mais référençant les processus explicitement Æ chaque processus peut avoir un comportement dépendant des messages reçus et de son identité

Serveur :

gère X

attendre demande(X) envoyer(X) à client

Client :

demander(X) attendre (X) :

P1

Réception de « message » Si a>3 envoyer message à P2 Calculer a

P2

Réception de « message » Si a>3 envoyer message à P1 Calculer a

• symétrie forte : Même texte mais ne référençant plus explicitement les processus Æ pour une même succession de messages, ils ont tous le même comportement.

• symétrie total : Même texte indépendant des messages Æ ils ont tous le même comportement.

P1

Réception de X Y := f(X)

Emettre Y

P2

Réception de X Y := f(X)

Emettre Y

Fourmis1

Si obstacle : contourner Si nourriture : manger Si prédateur : mourir Avancer

envoyer (position)

Fourmis2

Si obstacle : contourner Si nourriture : manger Si prédateur : mourir Avancer

envoyer (position)

♦ Qualités d’un algorithme distribué :

• Degrès de répartition : rôle joué par chaque processus Æ niveau de symétrie

• Résistance aux pannes : plus un algorithme distribué est symétrique, plus il possède une grande résistance aux pannes.

• Hypothèses sur les voies de communication : Moins il y a d’hypothèses, plus l’algorithme est généralisable.

• Trafic engendré.

• Absence de blocage.

• Détection de terminaison.

♦ Exemple de deux techniques de distribution

1) Le calcul diffusant (diffusing computation) : très utilisé pour faire des maths.

• Cas simple : accusé de réception = diffusion d’une information

• Cas complexe : chaque processus exécute une partie d’un algorithme

• Structure arborescente, non-symétrie (au moins pour le processus racine), attente.

Processus racine

Processus noeud

Processus feuille

Processus feuille (1) go !

(2) go !

(2’) go ! (3) ok !

(3’) ok ! (4) ok !

(1’) go !

(n) ok !

1) L’estampillage (Lamport) : cohérence temporelle

C consomme les messages dans l ’ordre de leurs

estampilles t=1

A

t=1->2 B

t=1->3 C

(m3,B,2) (m1,A,1)

Estampille = date à laquelle le message a été envoyé

A la réception, B met son

horloge à 1 A l émission, B incrémente

son horloge

2 estampilles identiques ?

hiérarchie entre processus

ex : (B,2>A,2).

Développer des algorithmes distribués

- Définir leurs caractéristiques :

- Sécurité : ce qui ne doit pas arriver - Vivacité : ce qui doit arriver

- Trouver l'algorithme non distribué - Vue Abstraite

- Pseudo-code

- Trouver l'algorithme distribué - Vue concrète

- Pseudo code -> code final

Sécurité versus Vivacité Sécurité : ce que l'algorithme empêche

Exemple de l'exclusion mutuelle : deux utilisateurs ne peuvent prendre ensemble la ressource.

Solution possible : ne jamais l'attribuer

Vivacité : ce que doit permettre l'algorithme

Exemple de l'exclusion mutuelle : si un utilisateur veut la ressource et qu'elle est disponible, il doit l'avoir.

Solution possible : lui donner sans réfléchir

Difficulté : Sécurité + Vivacité .

Exécution atomique

Algorithme distribué = fonctions atomiques

- Exécutée en section critique / autres fonctions du processus - non interruptible au sein du processus

- ne laisse pas le temps aux autres fonctions de modifier une variable

- l'arrivée d'un message n'est pris en compte qu'avant ou après son exécution

- plusieurs actions atomiques peuvent être exécutées en parallèle si elles ne font pas partie du même processus

Fonction particulière interruptible

- Attente d'un événement ou d'un changement d'état provoqué par d'autres fonctions - Pseudo – code : instruction attendre

Suite du cours :

Ce qu'on y trouve

- aspect "théorique"

- Compétition - Synchronisation - Etat global

- variables et ensembles - codage "générique"

- pseudo code : instructions envoyer, recevoir, attendre, tant que , pour, si

-

Ce qu'on n'y trouve pas - codage "spécifique"

- C : socket thread (signal) - Adda

- OCCAM : par, seq, ?, ! - Noyaux : OS9,VXWorks

Bilan de l’introduction :

• Algorithme distribué Æ Communication entre processus.

• Pas de mémoire commune Æ problème de représentation globale du programme

• Distribution des données, des calculs

• Distribution des algorithmes de distribution

- exclusion , élection, synchronisation, surveillance ….

• Algorithmes dépendant de la topologie.

• Systèmes complexes : Besoin de validation (réseaux de Petri, systèmes de transitions, logique temporelle ..)

2. Compétition : l’exclusion mutuelle répartie

Positionnement du problème

♦ l’objectif :

• Accorder un privilège à un processus parmis n (accès à une ressource non partageable…).

♦ Problèmes spécifiques :

• Equité (vivacité) : Tout processus ayant besoin de la ressource y aura accès au bout d’un temps fini Æ absence de blocage.

• Sûreté : A tout instant il y a au plus un processus accédant à la ressource.

• Minimiser les échanges.

♦ Modélisation du problème grâce aux RdP

T1

Fonctionnement sans besoin de la ressource : dehors_1

demande_1 Demande de ressource

Processus 1

T2

dehors_2 demande_2

Demande de ressource Processus 2

critique_1 critique_2

♦ RdP de la Solution centralisée :

T1

demande_1

Demande de

ressource ^T2

demande_2

Demande de ressource critique_1

critique_2 /V

Entre_1

Sort_1

Entre_2

Sort_2

♦ Implantation Centralisée solution matériel : Verrou et fonction test&set :

• Test&set = opération atomique Æ Impossibilité qu’entre consultation et affectation il y ait une autre consultation, instruction de base d’un µp : échanger(registre,mémoire)

Processus i :

Init : V = 0

//Demande_i

Attendre jusqu’à ce que test&set(V) = 0

//Entre_i

<Critique_i>

….

//Sort_i reset(V)

test&set(V) temp = V V=1

return(temp) reset(V)

V=0

♦ Echec de cette solution en architecture distribuée

• V ne peut être une variable commune, sa consultation peut prendre du temps

• test&set ne peut plus être atomique

Processus 1 V

Processus 2 consultation

modification

P1

P2 V

consultation

∆T

∆T

∆T

modification

Section critique test&set(V)

Section critique

♦ Solution basée sur les messages « alternating mutex algorithm »

• Problème : évolution globale, blocage.

T1

demande_1

Demande de

ressource ^T2

demande_2

Demande de ressource critique_1

critique_2

dehors_1

dehors_2 Message12

Message21

♦ Exemple d’algorithme d’exclusion mutuelle fonctionnant en architecture distribuée

• priorité au processus 1 (marquage initial)

Repos demande1

autorise1

Silence

Attente

AcExt1 critique

ReqExt1 ReqExt2

Attente

AcExt2 critique2

Silence

autorise2

demande2 Repos

equit1 equit2

♦ Version pseudo code : autorise_i et req_j sont des flags //Acquisition de la section critique

si (autorise_i==1)

entrer en section critique ou (non déterministe)

si (req_j = 1)

autorise_i = 0

envoyer accord(i) //mode silence

req_j = 0 aller en 2 fsi

sinon :

2) envoyer requête(i) attendre accord(j)

Entrer en section critique ……

Fin de section critique autorise_i =1

fsi

// réception de Requête(j) req_j = 1

si (autorise_i==1) autorise_i=0

envoyer accord(i) req_j = 0

fsi

♦ n processus : RdP Colorés

• Couleurs :

C = {<ci>, 1≤i≤n}

O = {<oi>, 1≤i≤n}

• Fonctions de changement de couleur :

f1(<ci>) = <oi>

f2(<oi,cj> )= <cj>

f3(<oi,cj> )= <ci>

Repos demande

autorisé

silence

attente1

Accord critique

Requete

<c1>

: :

<cn>

<c2>

: :

<cn>

<c1>

f2

<C>

<C>

<C>

f1

<oi, ci> f3

♦ Problème d’équitabilité

• Deux classes d’algorithmes

- Algorithmes fondés sur les permissions Permissions individuelles

Permission d’arbitre + : rapidité

- : compléxité

- Algorithmes fondés sur un jeton Mouvement perpétuel : + : simplicité

- : temps d’attente

Compromis : diffusion du jeton.

♦ Algorithmes fondés sur les permissions.

Notation : i est un processus ayant besoin de la ressource

Ri est l’ensemble des processus à qui i doit demander la permission

• Permissions individuelles :

P1 et P5 veulent la section critique Æ exclusion mutuelle car P5 demande à P1 donc P1 ne prendra pas la section critique s’il a autorisé P5.

Sûreté : ∀(i,j) : i∈Rj ou j∈Ri P1

R1={2}

P3

R3={1,5}

P2

R2={3,1}

P5

R5={1,2,4}

P4

R4={1,2,3}

demande

autorisation ou interdiction

• Permissions d’arbitres

P1 et P5 veulent la section critique Æ exclusion mutuelle par « l’arbitre » P3, qui ne l’accordera qu’à l’un des deux.

Sûreté : ∀(i,j) : Rj∩Ri ≠∅

P1

R1={3,4}

P2

R2={1,4,2}

P3

R3={2,4}

P4

R4={3,1}

P5

R4={2,3}

demande autorisation

♦ L’algorithme de Ricart et Agrawala : (permission individuelle)

• Avantage :

• Equité (l’attribution de la ressource commune s’effectue dans l’ordre des demandes) Variables de chaque site i :

Var état_i: {dehors, demande, critique} init à dehors h_i, last_i : entier croissant init à 0.

priorité_i : booléen ;

attendus_i, différé_i : ensemble de sites init à ∅

h_i est une horloge logique, rappel : (h,i)<(k,j) ⇔ (h<k ou (h=k et i<j)) last_i : date de la dernière demande de i

attendus_i : liste des sites devant fournir une reponse différé_i : liste des sites mis en attente par i.

♦ Quatre fonctions atomiques : (sauf la procédure attendre)

♦

♦

♦

Libérer : (sortie de S.Critique) etat_i := dehors ;

∀j ∈ différé_i : envoyer permission(i) à j ; différé_i := ∅

Acquérir :

etat_i := demande ;

h_i := h_i + 1 ; last_i := h_i ; attendus_i := R_i

∀j ∈ R_i : envoyer requête(last_i,i) à j ; attendre(attendus_i = ∅) ;

état_i := critique ;

Réception de requête(k,j)

h_i := max(hi, k) ;

priorité_i := (état_i≠dehors) et (last_i,i)<(k,j) ; si prioritéi alors différé_i := différé_i∪{j}

sinon envoyer permission(i) à j fsi ;

Réception de permission(j) attendu_i := attendus_i-{j}

♦ sûreté de l’algorithme de Ricart et Agrawala

• Deux processus i et j peuvent-ils être en section critique.

• Pour cela, deux messages requête(h,i) et requête(h,j) ont été envoyé et deux messages permission(i) et permission(j) ont été reçu.

• Cas 1) envoi d’une permission suivie d’une requête (processus j)

i

j

requête(h,i)

permission(j) requête(k,j)

lastj>hj hj≥h

dehors

k=h_j ⇒ k>h

last_i=h k>last_i⇒(lasti,i)<(k,j)

étati=demande

Permission refusée 2

10 10 11

11

11>2 2

• Cas 2) envoi « simultané » de 2 requêtes

i

j

requête(h,i)

requête(k,j)

test1 : (k,j)<(h,i)

hi=h

état_i=demande

étatj=demande

hj=k

test2 : (h,i)<(k,j)

(test1= ¬ test2)⇒une seule permission accordée lastj=k

lasti=h

♦ Vivacité de l’algorithme de Ricart et Agrawala

• Chaque requête possède une estampille distincte

• La requête d’estampille la plus faible sera toujours accordée

• Tout processus rentrant en section critique en sort au bout d’un temps fini

⇒ Vivacité assurée

♦ Trafic :

• Nb messages :

ƒ Une utilisation de la section critique requiert 2(n-1) messages

• Temps :

ƒ Si la section critique n’est pas utilisée, il faudra attendre 2T pour qu’un processus puisse l’acquérir. T = temps de transfert d’un message.

ƒ Si elle est utilisée, il faudra attendre T, une fois sa libération effectuée (temps de transfert du message d’autorisation)

♦ Robustesse vis-à-vis du déséquencement :

• Cas critique : déséquencement des permissions

Cqs où hi>hj (i prioritaire)

i

j

hi=α

h_j=β

requête(α+1,i)

permission(j)

critique

requête(α+1,i)

permission(j)

requête(β+1,j)

h_j=β+1 lastj=β+1

Jusqu’à ce que hi>lastj

♦ Structure des liaisons

• maillage complet bi-directionnel.

• peut s’adapter à d’autres structures, au détriment d’un surplus de trafic. Exemple : structure en anneau : n(n+1)/2 messages pour une utilisation de la section critique.

♦ Possibilité d’optimisation

• Si l’on connaît δ, temps de transfert maximum entre deux sites.

- Ne pas envoyer de permission positive.

- Envoyer un refus de permission, suivi d’une permission une fois la section libérée.

- Attendre un refus de permission durant 2δ, puis considérer que celle-ci est acquise.

toutes les permissions sont accordées : nb de messages pour 1 utilisation = n-1 aucune permission accordées : nb de messages pour 1 utilisation = 3(n-1)

Æ interessant si δ petit

♦ Problème des horloges non bornées :

• La valeur d’une variable informatique ne peut croître indéfiniement.

Æ les horloges possèdent un « modulo ».

• Comparaison d’horloges finies modulo 8 :

hi 1 2 3 4 5 6 7 8 1 2

hj 1 1 1 1 1 1 1 2 2 2

comparaison = > > > > > > > < =

• L’algorithme est perdu car hj est en réalité toujours < hi

♦ Problème des horloges non bornées

• Connaissance de l’écart Max entre 2 horloges, exemple ±2 :

hi 0 1 2 3 3 3 4 4 5

hj 0 0 1 2 3 4 5 6 7

comparaison = > > > = < < < <

• Les horloges peuvent être implantées modulo 4 :

hi 0 1 2 3 3 3 0 0 1

hj 0 0 1 2 3 0 1 2 3

comparaison = > > > = < < < <

Avec : 1>0 ; 2>0 ; 2>1 ; 3>1 ; 3>2 ; Mais : 0>2 ; 0> 3 ; 1>3 ; 1>0 ;

♦ Borne des Horloges de l’algorithme de Ricart et Agrawala

• Constat : Il ne peut y avoir deux requêtes successives par un processus sans qu’il n’ait reçu une permission.

Pour n processus :

• Il y a au maximum un écart de (n-1) entre la requête et l’autorisation

• Il y a au maximum un écart de (n-1) entre deux requêtes

⇒ La différence entre 2 horloges logiques est de ±(n-1) ⇒ modulo = 2(n-1)

hi

hj

hk

0

req(i,1) 1

req(j,2) 1

0 2

2

0 req(k,3)

Cas extrème : tous les processus en attente d’autorisation : horloges bloquées !

Permission(j)

♦ Algorithmes similaires :

Carvalho et Roucairol :

Si un site veut la section critique plusieurs fois de suite, alors qu’aucun site ne l’a demandé, il n’est pas obligé de faire plusieurs requêtes.

Adaptatif : les sites peuvent se déclarer consommateurs ou non consommateurs

potentiels de la ressource durant l’évolution de l’algorithme (l’ensemble Ri évolue dans le temps).

Les horloges ne peuvent plus être bornées.

Chandy et Misra : Adaptatif, Variables bornées,

L’identité des sites n’est plus utilisée, Algorithmes à permission d’arbitres

Algorithmes fondés sur l’unicité d’un jeton

♦ Algorithme de Le Lann (mouvement perpetuel)

• Le jeton tourne indéfiniment de processus en processus.

• Un processus demandeur porteur du jeton utilise la ressource commune avant de rendre celui-ci.

• Simple.

• Trafic inutile

• Si la section critique n’est pas utilisée il faudra attendre jusqu’à (n-1)T pour qu’un processus puisse l’acquérir Æ LENT ! !

Processus i jeton Processus j Processus k

♦ Algorithme à diffusion (le jeton est distribué au demandeur)

• Un processus demandeur lance une requête.

• Le jeton possède l’info « combien de fois ai-je été consommé par Pn ».

• Chaque processus compte le nombre de requêtes reçues des autres processus.

• un processus p est demandeur si

jeton[p] < tab[p] (le jeton est alors envoyé à p) Processus i

Processus j

Processus k j

k 0 1

i k

1 1

i j

1->2 2

i j k 1 2 1 requête(i)

requête(i) tab

tab

tab

jeton

♦ Algorithme à diffusion (suite).

• Pas de blocage

• Vivacité : Possibilités de famine : toujours les mêmes servis.

Solution : chaque processus opère ses tests dans un ordre différent,

Exemple : chaque processus i effectue ses tests dans l’ordre i+1, i+2 …n, 1, ..i-1

• Nombre de messages pour une utilisation de la section critique : de 0 à n.

• Delai durant lequel la section critique est inutilisée alors qu’elle est demandée : 0 à 2T

♦ Répartition d’un sémaphore :

• Rappel : Sémaphore centralisé : partage de n ressources Processus1

P(S) ;

Utiliser ressource ; V(S)

Processus2 Processusj

Sémaphore S P(S),

V(S)

P(S), V(S)

P(S), V(S)

P(S) : attendre (S>0) ; S=S-1

V(S) : S=S+1

♦ Sémaphore distribué : principe

• P(S) doit être exécuté en section critique Æ exclusion mutuelle.

• V(S) n’est pas critique, S doit être distribué (jeton).

Processus 1 nbVs₁

P(S) V(S)

Processus 2 nbVs₂

P(S) V(S)

Processus n nbVs_n

P(S) V(S)

Jeton : nbPs

attendre (S>0)

≈

#P(S) < S₀ + #V(S)

P(S) : acquérir jeton

attendre (nbPs<S₀ + nbVi) ; nbPs=nbPs+1

libérer jeton

S = #V(S) - #P(S) + S₀, (#P ≈ nb exécution de P, S₀≈ nb ressources)

V(S) : envoyer incr Réception incr : nbVi = nbVi+1 incr

incr jeton

distribué

• Sûreté :

nbVsi ≤ # V(S) et nbPs = # P(S )

Donc :

(nbPs<(S₀ + nbVi)) ⇒ (#P(S) < (S₀ + #V(S)).

Le test est sûr vis-à-vis d’un sémaphore centralisé

• Vivacité : dépend de l’algorithme de déplacement du jeton gérant l’exclusion mutuelle d’accès à P(S).

• Trafic Important (trafic de l’algorithme d’exclusion mutuelle lié à P + trafic lié à V) Æ Les sémaphores répartis ne sont intéressants que lorsqu’une simple exclusion mutuelle ne suffit pas.

Problèmes plus complexes :

♦ Lecteurs-écrivains réparti

• Exclusion mutuelle à deux types d’opérations « lire » et « écrire » dotée de règles d’exclusions spécifiques.

Æ Adaptation des algorithmes d’exclusion mutuelle répartie

Problèmes plus complexes :

♦ Allocation répartie de ressources

• Problème spécifique : l’interblocage : Scénario : 1Æ3Æ ?

• Solutions :

- demande incrémentale - demande simultanée

Processus 1 : :

1 requérir R1 :

2 requérir R2 :

libérer R1 :

libérer R2

Processus 2 : :

3 requérir R2 :

4 requérir R1 :

libérer R1 :

libérer R2

Processus n : :

♦ Demande incrémentale :

Hiérarchie des ressources R0<R1<R2….

Un site ne peut demander une ressource Ri que s’il a déjà obtenu toutes les ressources (dont il a besoin durant la session), qui sont inférieures à Ri.

Chaque ressource gère une file d’attente fifo des sites qui la réclament.

Le chemin 1Æ3Æ….. n’est plus possible !

Simple, mais peu performant (beaucoup d’attente).

♦ Demande simultanée : principe

Estampillage des messages de requête avec horloge logique (exclusion mutuelle de Ricart et Agrawala)

• Cas pour une ressource en M exemplaires, utilisée k_i fois par chaque processus i.

Processus 1 Utilisé₁

P2 P3 M M Différé{}

Processus 2 Utilisé₂

P1 P3 M M Différé{}

Processus 3 Utilisé₃

P1 P2 M M Différé{1}

requête(h,1)

requête(h,1)

Pas interessé : libre(3,M) Ou pas prioritaire

Prioritaire : libre(3,M-k₃) Injection de 1 dans différé, et envoie de libre(3,M) à 1 suite à la libération des ressources

• M - ∑utilisé_i[j] ≥k_i Æ consommation des ki ressources

• Lors d’un envoi de requête, utilisé_i[j] := M (pire des cas)

• Lors d’une réception de libre(j, N), utilisé_i[j]=utilisé_i[j]-N

• Généralisation possible à plusieurs types de ressources

3. Coordination : La synchronisation répartie

Coordination par rendez-vous

♦ Un rendez-vous multiple r = {i,j,k}

Processus i Invoquer r

Invoquer r

Invoquer r

Rendez - Vous.

Processus j

Processus k

temps

♦ Choix non déterministe entre plusieurs rendez-vous

♦ Problèmes spécifiques :

• Coordination synchrone : si un processus s’engage dans un rendez-vous, tous les processus concernés doivent s’y engager.

• Exclusion : un processus ne peut être que dans un rendez-vous à la fois.

Processus i Invoquer r1 ou r2

Invoquer r1 ou r4

Invoquer r3 ou r1

Rendez - Vous

r1 Processus j

Processus k

temps

♦ Principe de la solution pour un rendez-vous : Sémaphores privés.

• Si un processus i veut prendre le rendez-vous, il incrémente le sémaphore des autres sites : ∀x ∈ r , x≠i : V(Sx).

• Un processus i peut entrer en rendez-vous, s’il a pu décrémenter Card{r}-1 fois son propre sémaphore :

faire Card{r}-1 fois P(Si)

entrer en rendez-vous

Processus j Processus i Processus k

Sj = 1 V(Sj) V(Sk) Si = 0 Sk = 1

♦ Principe de la solution centralisée pour n rendez-vous demandés simultanément

• wi : nombre de fois où i a été demandeur

• ni : nombre de fois où i est entré en rendez-vous

• invariants : chaque processus ne s’engage que dans un rendez-vous à la fois

∀i : ni ≤ wi ≤ni+1

un rendez-vous rj ne peut avoir lieu que si tous les sites sont prêts

∀rj : (∀i ∈rj : wi = ni +1) ⇔ rj peut avoir lieu.

Processus controleur wi=1

ni=0 wj=1 nj=0 wk=0 nk=0

r1{i,j}

r2{j,k}

r3{i,j,k}

Processus i Processus j Processus k prêt(i)

prêt(j) ok(r1)

♦ Principe de la solution distribuée pour n rendez-vous demandés simultanément

• Le jeton assure l’exclusion mutuelle des contrôleurs

• Quand un contrôleur envoie ok(rj), il incrément nx(j)

Sens des modifications wi=1Æreq(i)Ænbreqn(i) nx(i) Æok(rl)Æn(i)

Processus i

ni=0 ; wi=1 ; ctl_par{z,x}

Processus j

nj=0 ; wj=1 ; ctl_par{x,y,z}

Processus k

nk=0 ; wk=1 ; ctl_par{z,y}

Processus controleur z

rdv_ctl_z{r1{i,j},{r2{i,k}}

proc_ctl_z{i,j,k}

nbreqz(i)=1 nbreqz(j)=1 nbreqz(k)=0

Processus controleur x rdv ctl x{…….}

Processus controleur y

Circulation jeton (mutex)

Jeton{nx(i)=…, nx(j)=…,nx(k)=…}

prêt(i) prêt(i)

ok(r1)

nx(i) : nombre de fois où OK(r…) a été envoyé à i

Coordination par maintien d’un invariant

♦ Exemple d’invariant

• Producteurs consommateurs :

#autorisation(produire) - #terminer(consommer)≤k (taille du buffer)

#autorisation(consommer) - #terminer(produire) ≤ 0

• Cas général, Synchronisation : ∑

= <

m i

k x_i

i

1

α . (α_i = constantes)

• Pour maintenir un invariant, les processus doivent évaluer une condition avant de modifier une des variables de l’invariant. (avant de produire, il faut vérifier qu’il y a de la place dans le buffer)

• Problème spécifiques :

• Sûreté : si la condition est fausse, aucun processus ne peut l’évaluer à vraie

• Vivacité : Si une condition est vraie, tous les sites doivent la voir vraie au bout d’un temps fini.

♦ Cas des variables liées à un processus :

• xi, xj et xk sont des compteurs à évolution monotone et croissante

• Vue abstraite, Conditions Abstraites

Processus i Condition : xi-xj-xk<k xi

Processus j Condition : xj-xi-xk<k xj

Processus k Condition : xk-xj-xi<k xk

♦ Minorants et mise à jour retardée : condition de type « mk(xi) ≥ valeur » Condition Concrète (xi≥ valeur ) ⇒ Condition Abstraite (mk(xi) ≥ valeur)

• Vue Concrète :

mn(xm)≤ xm Æ MajR

• Sûreté :

xk-mk(xi)-mk(xj) <k ⇒xk-xi-xj<k Processus i

xi, mi(xj), mi(xk)

Processus j

xj

Processus k Condition :

xk-mk(xi)-mk(xj)<k xk, mk(xi), mk(xj) mk(xj)

mi(xj)

♦ Majorant et mises à jour anticipées : condition de type « Mk(xi) ≤ valeur »

• Si Mi(xj)≤xj alors (Condition Concrète ⇒ Condition Abstraite)

• Il faut au contraire que Mi(xj) ≥ xj Æ MajA xi+Mi(xj)-mi(xg) < k

xj ≤Mi(xj), MajA xg≥mi(xg) MajR

Vue abstraite : i

xi+xj-xg<k xi

i

xi+Mi(xj)-mi(xg)<k xi

Vue concrète :

⇒ xi+xj-xg<k

♦ Mise à jour anticipée : implantation

• Possibilité de blocage Æ si l’incrémentation de xi est dépendante de Mi(xj)<k) Algorithmes spécialisés limitant le crédit n.

♦ Compteur à évolution quelconque

• On décompose l’évolution d’un tel compteur par le biais de deux compteurs (un compteur d’incrémentation et un compteur de décrémentation). Les algorithmes précédent sont ensuite utilisables.

j

……..

……..

envoyer(inc(j,n)) attente(ok)

xj = xj+n

i

reception(inc(j,n)) Mi(xj)= Mi(xj)+n envoyer(ok)

inc(j,n)

ok

♦ Variables non liées à un site

• Exemple : vue abstraite de la gestion d’un parking

• Invariant à maintenir : e≤s+p (capacitée du parking)

• Avant d’autoriser une entrée, un processus vérifie que e<s+p Entrée/sortie1

Entrée : e=e+1 Sortie : s=s+1

Entrée/sortie2 Entrée : e=e+1 Sortie : s=s+1

Entrée/sortie2 Entrée : e=e+1 Sortie : s=s+1

♦ Technique d’éclatement

• Chaque site i transmet sa valeur ei et si

• (MajR pour si et MajA pour ei)

• Vue Concrète :

• Problème : beaucoup de messages Entrée/sortie1

e=

∑

i

ei s=

∑

i

si e1,s1

Entrée/sortie2 e=

∑

i

ei s=

∑

i

si

e2,s2 Entrée/sortie3

e=

∑

i

ei s=

∑

i

si e3,s3 e3, s3

e3, s3 e1, s1 e1, s1

e2, s2 e2, s2

♦ Partitionnement et contrôle isarithmique :

• Chaque processus i gère une partie des places pi.

• Avant d’autoriser une entrée, un processus vérifie que ei<si+pi p=∑pi

• Blocage si les voitures arrivent « par un processus » et partent « par un autre ».

solution Æ Chaque pi évolu dynamiquement à l’aide de messages de crédits, en fonction d’un seuil, afin d’éviter les blocages.

Entrée/sortie1

e1,s1,p1

Entrée/sortie2 Trop de place p2=p2-n

e2,s2,p2 Crédit(n)

p1=p1+n

Coordination par construction d’un temps virtuel

♦ Objectif :

• Avoir une base de temps permettant de faire abstraction des problèmes liés aux temps de transit des messages.

• Implanter des algorithmes distribués comme si le système était global.

♦ Exemple : exy sont des « événements » devant être partagés par deux processus Pi et Pj.

• En non réparti, les deux processus verraient ei1, ej1, ej2, ei2.

Pi

Pj

ei1 ei2

ej1 ej2

t

t

♦ Horloge virtuelle

• principe : l’émetteur d’un message précise la date virtuelle à laquelle celui-ci doit arriver (m,t).

• Le récepteur connaît la date virtuelle à laquelle est arrivé le message.

• Problème à résoudre :

Gestion de l’évolution de l’horloge virtuelle La cohérence temporelle (sûreté)

• Tous les processus ont la même perception de l’horloge virtuelle

• Un message estampillé à la date z doit être consommé à la date z La vivacité

• Si du point de vu d’un processus, le temps virtuel peut progresser, il progressera.

♦ Solution centralisée

• Un processus maître gère l’horloge virtuel hv

• Les autres processus des dates de réception des messages envoyés

• beaucoup de messages, processus souvent en attente (diminution du parallélisme), faible répartition.

Processus maitre

hv = i

Processus n

Tampon d’attente (mi,h) (mj,k) hv

hv

hv Message emis devant

être recu a… Si hv=h, alors consommer mi

….

♦ Solution décentralisée :

• Chaque processus possède une image de l’horloge virtuelle

• Quand un message est consommé, le processus récepteur met son horloge à jour.

Problème d’interblocage :

• Le processus j doit-il consommer le message (m,k+d), ou existe-t-il un message arrivant de z à une date inférieure. J est bloqué et se met en attente.

• z, peut être dans le même cas, à cause d’autres processus : interblocage.

Pi

hvi = k

Pj

hvj = … (m,k+d)

Pz

♦ Méthode pessimiste de Chandy et Misra

• Quand un processus n envoi un message (m,y) à un processus p, il envoi également un message (null,y) aux autres processus.

• Lorsqu’un processus j reçoit (null,y) d’un processus z, il sait que ce dernier ne lui enverra pas de message avant y.

• Chaque processus connaît donc la date minimum à partir de laquelle chacun des processus entrant peut lui transmettre un message. Il est donc capable de décider du prochain message à accepter et de la valeur de son hv.

• Ici : Si Pj ne possède que deux liaisons entrantes (en provenance de Pi et de Pz), il peut consommer (m,6) et positionner hvj à 6.

Pi

hvi = 5

Pj

hvj = 4Æ6 i :6

z :7 (m,6)

Pz

hvz = 6 (m,7) (null,7)

♦ Interblocage et méthode pessimiste :

• Pk peut recevoir des messages de Pj qui peut en recevoir de Pk

1) k envoi (m1,5) à z, (null,5) à j.

2) j reçoit (m2,10), il consomme (null,5) et met hvj = 5.

3) j met (m2,10) en attente car il attend le prochain message de k (pour faire un choix).

4) k attend un message de j (qui est en attente de k), conditionnant le prochain message qu’il enverra Æ Interblocage.

Pi Pj

i : 2 j : 5

Pk Pz

(m2,10) (m1,5)

(null,5)

♦ Méthode pessimiste et anticipation.

• A la réception de (null,y), un processus sachant (par anticipation) qu’il n’enverra rien avant y+δ, envoi sur toute ses liaisons (null, y+δ)

1) k envoi (m1,5) à l et (null,5) à j.

2) j sait que k ne lui enverra pas de message avant 5 (hvj = 5).

3) j recoit (m2,10).

4) j sait qu’il n’enverra rien avant δ.

5) j envoi (null,5+δ) à k

6) k sait qu’il n’enverra rien avant 5+δ’

7) k envoi (null,5+δ’) à j

8) 5+δ’’…>10Æ j accepte (m2,10) Æ Plus d’interblocage i

j

k

l

(m2,10)

(null, 5+δ) (null, 5), (null, 5+δ’) (null, 5+δ’) (m1, 5)

♦ Méthode optimiste de Jefferson

• Principe :

ƒ Elaboration d’une sauvegarde des états locaux des processus : ensemble des valeurs des variables du processus à un instant donné.

ƒ Une sauvegarde des messages émis et reçus.

ƒ Une prise en compte immédiate d’un message (m,hv) dès qu’il arrive.

ƒ Si un message (m’,hv’) arrive avec hv’<hv : Exécution d’un retour arrière de l’évolution du processus :

ƒ Recalage de l’état du processus sur l’état sauvegardé précédent ou égal à hv’

ƒ Annulation des messages émis depuis hv’, par l’envoi d’un anti message.

ƒ La réception de l’anti-message d’un message déjà consommé provoque un retour arrière du récepteur à la date du message.

♦ Exemple :

Pi

Sauvegarde i10

hvi

10 12 14 15

Pj hvj

9 10

Sauvegarde j9

13 (m,13)

(m’,14)

Sauvegarde j13 (m’’,12)

Retour arrière Vers j9

Pi hvi

15

Pj hvj

9

anti(m’,14)

Retour arrière Vers i10

anti(m,13)

10 ƒ Compromis # sauvegarde ↔ précision

des décalage (temps)

ƒ Quelles sauvegardes peuvent être effacées ?

♦ Temps Virtuel Global (GVT)

ƒ Le GVT est la borne inférieure sur les dates de retour arrière possibles.

GVT = min({hvi : 1≤i≤n}∪{t : un message (m,t) est en transit}

ƒ Le GVT est calculé à l’aide d’un algorithme réparti d’observation (chapitre suivant)

4. Observation et état global

Détection répartie de la terminaison

♦ Objectif :

• Savoir si une application répartie est terminée, sans faire aucune hypothèse sur la structure ou l’organisation de celle-ci (surveillance d’un calcul)

♦ Sûreté :

• Si l’observation indique que le calcul est terminé, alors le calcul est effectivement terminé

♦ Vivacité :

• Si le calcul se termine, alors l’algorithme de détection annoncera sa terminaison au bout d’un temps fini.

♦ Principe :

• Un processus doit être « actif » pour envoyer des messages

• Un processus dans l’état actif peut passer dans l’état passif (fin d’un sous-calcul)

• Lorsqu’un processus dans l’état passif reçoit un message, il repasse dans l’état actif.

⇒ Le calcul global est terminé si tous les processus sont inactifs et qu’il n’y a aucun message en circulation

♦ L’algorithme de quatre compteurs

• Hypothèse d’un modèle atomique :

• les temps de calcul sont infiniment courts

• Seules les communications prennent du temps

Æ Un calcul est terminé si ∑messages émis = ∑messages reçus

• 2 Compteurs associés à chaque processus i :

ei : nombre de messages émis par i ri : nombre de messages reçus par i

• Un processus particulier demande la valeur des compteurs aux autres processus.

♦ Pourquoi 2 compteurs ne suffisent pas :

ei(tj) = valeur de e renvoyépar i au temps t

1 2

3

temps-réel

Vague de consultation

t3 t2 t1

∑

∑

⎭ =

⎬⎫

=

=

=

=

=

=

i

i i i

i

i t R r t

e

E ( ) ( )

0 ) (t r 0, )

(t r 1, ) (t r

0 ) (t e 1, ) e2(t 0,

) (t e

3 3 2

2 1

1

3 3 2

1 1

♦Solution : 2 Vagues de consultation (E1,R1) et (E2, R2)

R1 = E2 ⇒ terminaison

♦preuve :

définitions : d_i et f_i ≡ début (fin de la vague i)

R(t), E(t) ≡ Nombre de messages reçus (émis) au temps t.

Faits :

1 : d₁<f₁<d₂<f₂

2 : e_i(t) ≤ e_i(t’) et r_i(t) ≤ r_i(t’) ∀t ≤ t’

2 : E(t) ≤ E(t’) et R(t) ≤ R(t’) ∀t ≤ t’

3 : R(t) ≤ E(t) ∀t 4 : R1 ≤ R(f1)

5 : E(d2) ≤ E2

Démonstration : Si R1=E2

Alors E2 ≤ R(f1) (4)

Donc E(d2) ≤ R(f1) (4+5) Si E(d2) ≤ R(f1)

Alors E(f1) ≤ R(f1) (car E(f1)≤E(d2)) (1+2) Or E(f1)≥ R(f1)

Donc E(f1) = R(f1)

Il n’y avait plus de messages en court à la fin de la 1^er vague

♦Algorithme général :

• Plus d’hypothèses sur le temps de calcul des processus, ni sur les caractéristiques des liaisons.

♦Structure de la solution :

Prédicats :

vide(i,j) ≡ la liaison entre i et j est vide pass_i = (état_i = passif) et (

∧

∈voi de i

j sin

vide(i,j))

≡ i est passif et tous les messages qu’il a envoyé ont été reçus.

term =

∧

i

pass_i ≡ le calcul est terminé

Détection répartie de l’interblocage

♦Objectif :

• Savoir si plusieurs processus « s’inter-bloquent » lors d’un calcul plutôt que d’éviter l’interblocage (les méthodes pessimistes sont souvent trop restrictives)

♦Sûreté :

• Si l’algorithme de contrôle annonce qu’il y a interblocage, celui-ci est effectif.

♦Vivacité :

• Si un interblocage existe, il doit être détecté en un temps fini

♦Difficulté particulière :

• Seul un sous groupe des processus gérant un calcul peuvent être concernés par un interblocage

• Il est souhaitable qu’un seul processus détecte l’interblocage

♦Interblocage sur allocation de ressource

• p1 attend une ressource de p2 qui attend p3 qui attend p1

Graphe des processus en attente

• Détecter un interblocage revient à détecter une boucle dans le graphe des processus en attente.

1

2 3

♦Interblocage sur communications

• p1 attend un message de p2 ou de p3 ou de p4 ….

• p2 attend un message de p4 ou de p3

• détecter un interblocage revient à détecter :

1) que le graphe des attente est une composante fortement connexe 2) qu’il n’y a aucun message en transit entre les processus du graphe

1

2 3

4

plus d’interblocage

♦Algorithme de Mitchell et Merrit

• Interblocage par allocation

Principe :

• Au moment d’un blocage, une valeur unique est calculée par le processus bloqué

• Cette valeur se propage par consultation/mise à jour des processus bloqués

• Si un processus bloqué constate que le processus bloquant possède la valeur qu’il a lui même calculé, c’est qu’il y a interblocage

♦Mise en œuvre

• Chaque processus i possède : une étiquette priv_i, une étiquette pub_i

• L’opérateur sup(pub_i, pub_j) renvoi une valeur supérieure à pub_i et pub_j R1 : règle de blocage

Lorsque le processus i se bloque en attente d’une ressource possédée par le site j, il redéfinit ses étiquettes : pub_i = priv_i = sup(pub_i, pub_j)

R2 : Règle de propagation

Lorsque i est bloqué par j, il consulte régulièrement la valeur de pubj et effectue : si pub_i<pub_j alors pub_i = pub_j fsi

R3 : Règle d’activation

Lorsque j libère une ressource demandée par i,k,… celle-ci est allouée à l’un d’entre eux.

Les autres processus sont désormais bloqués par celui qui a été choisi et appliquent la règle R1 avec lui.

R4 : Règle de détection

Si suite à la règle R2, un site i bloqué par j constate pubi = privi = pubj ⇒ il est sur un circuit et il est le seul à le savoir.

♦Algorithme de Chandy, Missa et Haas

• Interblocage par communication : détection d’une composante fortement connexe.

Diffusion d’un message « question(i,j) »

• Un processus recevant 2 fois « question() » fait parti d’une boucle

• Si tous les processus « fils » d’un processus donné font parti d’une boucle, il existe une composante fortement connexe.

1

2

3 4

question(0,1)

0 question(1,4)

question(1,3) Graphe des

processus en attente