Compétition : l’exclusion mutuelle répartie

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

♦ 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

♦ 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

Entrer en section critique ……

Fin de section critique autorise_i =1

fsi

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

♦ 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

♦ 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

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 ;

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

• 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

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

♦ 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

• 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 :

♦ 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

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

Dans le document Algorithmes de mise en œuvre des systèmes répartis (Page 27-61)