Structure en arbre avec des niveaux de synchronisation

Toutes les solutions précédentes ont un point en commun, l'accès à une section critique se fait de façon totalement exclusif (i.e un seul processus est présent à la fois en section critique). Dans le cadre des systèmes de chiers distribués, cette caractéristique est trop restrictive. En eet, l'opération de lecture sur un chier ne remet pas en cause la cohérence des données puisqu'elle n'en modie pas le contenu, elle ne nécessite donc pas un accès exclusif. En réalité seule l'opération d'écriture, qui modie la donnée, requiert un accès

totalement exclusif. Autrement dit, tous les algorithmes précédents ne permettent pas le partage des chiers en lecture. Pour remédier à ce problème, on peut alors utiliser des niveaux de synchronisation (ou mode de synchronisation). Le schéma le plus classique provient des systèmes de chiers centralisés, où un verrou dispose de trois états :

• Φ, le verrou n'est détenu par aucun processus ; • R, le verrou est détenu par un ou plusieurs lecteurs ; • W, le verrou est détenu par un seul écrivain.

La compatibilité entre ces modes de synchronisation est présentée dans le tableau 3.4. Seul le mode W est exclusif, c'est-à-dire qu'aucun autre écrivain ou lecteur ne peut accéder au chier. En revanche, dans le mode R, plusieurs processus peuvent lire le chier simultané- ment. Cette méthode permet d'augmenter la concurrence d'accès, en autorisant plusieurs processus à entrer en section critique lorsque les opérations eectuées sur le chier n'en modient pas le contenu.

Détenu

Demandé Φ R W

R + + -

W + - -

Fig. 3.4  Compatibilité des niveaux de synchronisation

Cette méthode est également utilisée dans les systèmes de chiers distribués, en amélio- rant la structure en arbre présentée dans la section 3.2.3. Dans cette approche, un n÷ud qui dispose d'un verrou, peut attribuer à ses n÷uds ls dans l'arbre, un verrou compatible avec le sien (tableau 3.4). De cette façon, lorsque le niveau de verrouillage demandé n'est pas un mode exclusif, il n'est pas nécessaire de posséder le jeton pour entrer en section cri- tique. Seuls les accès exclusifs nécessitent la possession du jeton. Dans notre exemple, cela correspond aux opérations d'écritures. Cette solution présente un autre avantage important lorsque le mode d'accès est partagé : les requêtes n'ont pas forcément besoin d'atteindre la racine de l'arbre pour être satisfaites. En eet, si le n÷ud parent possède un accès à la section critique dont le niveau est compatible avec celui qui est demandé, il peut satisfaire la requête de ses ls sans la transférer jusqu'à la racine. Toutefois, lorsqu'une requête arrive jusqu'à la racine (i.e le possesseur du jeton) et que le mode de verrouillage demandé n'est pas compatible, soit le n÷ud racine répond négativement à la requête, soit il la place dans une le d'attente, pour la traiter plus tard lorsque le statut du verrou aura changé (i.e lorsque tous les ls auront révoqué le verrou).

Normalement, lorsqu'un n÷ud termine sa section critique, il le signie à son n÷ud parent dans l'arbre (i.e il révoque le verrou). S'il souhaite à nouveau entrer en section critique, il doit alors redemander le jeton en envoyant une requête à son n÷ud parent. Or,

3.2. Les algorithmes à jeton 39 il n'est pas rare qu'un n÷ud accède plusieurs fois à la même section critique. Une solution pour améliorer la révocation des verrous, consiste alors à utiliser un cache [BRSL01]. Ainsi, lorsqu'un n÷ud termine sa section critique, au lieu de rendre le verrou, il le conserve dans son cache de verrous local, dans le but de le réutiliser plus tard sans envoyer de requête supplémentaire à son parent dans l'arbre. De ce fait, dans la mesure où le niveau de verrou détenu dans le cache est compatible avec le niveau demandé, toutes les requêtes provenant des processus s'exécutant sur le n÷ud, ne génèrent aucun message supplémentaire sur le réseau. Evidemment, si le mode de verrou demandé par un processus n'est pas compatible avec celui présent dans le cache, la requête doit être transmise à la racine de l'arbre.

Lorsque le n÷ud racine traite une requête dont le niveau de verrou demandé est incom- patible avec celui détenu par un ou plusieurs de ses ls, il doit envoyer à ces derniers, des messages d'invalidation de leur cache respectif. De plus, chacun des ls de la racine gère l'invalidation des caches de ses propres ls. En eet, à partir du moment où un n÷ud dis- pose d'un verrou dans son cache, il peut attribuer un verrou compatible à ses ls. Ainsi, la requête de révocation du verrou, est propagée à travers les branches concernées de l'arbre. Lorsque tous les caches sont invalidés, le n÷ud racine peut satisfaire la requête suivante.

Remarque : dans notre exemple, le jeton est transmis uniquement lorsque le mode d'ac- cès demandé est exclusif (e.g écriture dans un chier).

Cette méthode propose une dimension hiérarchique diérente de celle présentée dans la section 3.2.4 (i.e approche hiérarchique). En eet, ici la hiérarchie n'est pas liée à l'ar- chitecture de la grille et aux communications inter-site et intra-site qui la caractérisent. La dimension hiérarchique introduite ici correspond aux niveaux de synchronisation. Le n÷ud disposant du jeton n'est plus le seul à pouvoir décider de l'entrée d'un processus en section critique. Lorsqu'un n÷ud reçoit une requête, s'il possède un verrou compatible avec celui demandé, il peut satisfaire immédiatement la requête sans la transférer à son n÷ud parent dans l'arbre [DM03, Des03].

La gure 3.5 illustre cet algorithme. Dans cet exemple, un n÷ud est représenté par le triplet (O, H, P ) :

• O pour Owned, c'est le type de verrou que le n÷ud peut attribuer à ses ls ;

• H pour Held, représente le mode dans lequel le n÷ud accède actuellement à la section critique ;

• P pour Pending, c'est le verrou que souhaite obtenir le n÷ud.

Par exemple, le triplet A(W, W, 0) signie que le n÷ud A possède le jeton et qu'il est actuellement en section critique avec un verrou de type W. De plus, sur le graphe, un couple {N÷ud, Verrou} indiquera la nature de la requête à traiter. Par exemple, {C,W}

Fig. 3.5  Algorithme à jeton : approche hiérarchique en arbre indique que le n÷ud C souhaite obtenir un verrou de type W.

Initialement (gure 3.5.a), la section critique est partagée par trois n÷uds A, B et D, le jeton est détenu par A. Ensuite, C envoie une requête à B indiquant qu'il souhaite obtenir un verrou en mode W (gure 3.5.b). B ne disposant pas dans son cache d'un ver- rou compatible avec W, il transfère la requête à son n÷ud parent dans l'arbre. A reçoit alors la requête, mais ne peut la satisfaire immédiatement car le mode de verrou demandé est incompatible avec celui déjà attribué à A, B et D. Il envoie alors un message à B, lui demandant la révocation du verrou dans son cache. Ce dernier transfère la requête à son propre ls D, auquel il avait auparavant coné un verrou du même type. A doit alors attendre que tous les n÷uds sur A, B et D terminent leur section critique (gure 3.5.c) et lui signient que le cache a été invalidé. A peut alors satisfaire la requête {C,W}, en transférant le jeton au n÷ud C (gure 3.5.d). Notons au passage, que grâce au message d'invalidation, les n÷uds B et D changent également de n÷ud père.

Cette approche est très intéressante pour un système de chiers distribués. En eet, elle décharge le n÷ud qui dispose du jeton car certaines requêtes seront traitées directement

3.2. Les algorithmes à jeton 41 par d'autres n÷uds. De plus, lorsque les requêtes n'ont pas besoin d'atteindre la racine de l'arbre, l'algorithme génère moins de messages sur le réseau et l'accès à la section critique est d'autant plus rapide. Malheureusement, la structure en arbre ne permet pas de garan- tir que le temps d'obtention du verrou soit minimal. En eet, nous avons vu que cette technique pouvait produire des arbres très déséquilibrés, dont la hauteur pouvait croître, amenant ainsi les requêtes à voyager à travers plusieurs relais inutiles (cf. section 3.2.3). Ce phénomène est amplié par la latence du réseau, lorsque la requête est relayée à travers plusieurs sites de la grille. Dans l'exemple de la gure 3.7, nous montrons un cas pire où cette solution atteint ses limites. Pour cela, nous avons rajouté aux branches de l'arbre, les latences qui caractérisent les communications père/ls. Les valeurs des latences ont été choisies en se basant sur les caractéristiques de la plate-forme Grid'5000 en France [GHVBPS06]. L'exemple est constitué de trois sites, les n÷uds A et E sont situé sur le site S1, les n÷uds B et C sur le site S2, enn le n÷ud D sur le site S3. Les latences inter-site et intra-site sont représentées dans le tableau 3.6

S1 S2 S3

S1 0,5 ms 10 ms 9 ms

S2 10 ms 0,5 ms 5 ms

S3 9 ms 5 ms 0,5 ms

Fig. 3.6  Latences caractérisant les trois sites (S1, S2 et S3 )

Initialement, A dispose du jeton (gure 3.7.a). B demande alors un verrou de type W. Étant donné que le n÷ud A n'est pas en section critique, il peut transmettre le jeton à B. Ce dernier devient alors la racine de l'arbre (gure 3.7.b). Nous nous trouvons alors dans une situation où les n÷uds C, D et E ont pour parent le n÷ud A. Si l'un d'entre eux désire entrer en section critique, il devra d'abord envoyer sa requête à A, qui la transférera à B (gure 3.7.c). Dans l'exemple, nous prenons le cas du n÷ud C car c'est le plus révélateur du problème sous-jacent. En eet, bien que C soit situé sur le même site que B, il doit tout d'abord envoyer sa requête à A, qui lui est situé sur un site distant. Au nal, pour obtenir le verrou, C mettra au minimum 20,5ms (requête vers A, transfert vers B, puis réponse de B directement à C ), alors que les deux n÷uds sont des voisins direct sur le site S2. Il aurait donc pu obtenir le verrou en 1 ms, s'il avait directement envoyé sa requête à B. De la même manière, D mettrait 24ms pour obtenir le verrou, alors qu'une requête directe à C n'aurait coûté que 10ms (gure 3.7.d). Cet exemple pourrait encore être développé pour augmenter la hauteur de l'arbre, menant ainsi à une situation où une requête voyage à travers plusieurs sites. Etant donné que l'algorithme ne prend pas en compte la localisation géographique des n÷uds de l'arbre, on peut être amené à eectuer des requêtes coûteuses en temps car le n÷ud parent est situé sur un site distant, alors qu'un voisin aurait pu nous

donner l'accès à la section critique plus rapidement.

Fig. 3.7  Étude d'un cas pire pour une approche hiérarchique en arbre