Un exemple de protocole non tolérant aux fautes

– Quelle est la valeur finalement attribuée à la donnée en cas d’écritures concurrentes ? – Autorise-t-on les lectures concurrentes à une écriture ?

– Quelle est la valeur retournée par une lecture d’une donnée lorsque qu’il y a une écri-ture concurrente ?

– Autorise-t-on les lectures concurrentes ?

Les applications qui partagent les données doivent savoir quelles garanties sont offertes en terme de cohérence. Par exemple : la valeur retournée par une lecture prend-elle toujours en compte toutes les écritures qui ont été effectuées auparavant ? Ou encore : un processus est-il seul à accéder à la donnée pendant une période de temps donnée ? Souvent, un proces-sus doit pouvoir effectuer une lecture et une écriture sur une donnée partagée de manière atomique. Ce sera le cas notamment si un processus doit incrémenter la valeur d’une va-riable :x := x+ 1. Pour rester cohérente, la valeur de la donnée ne doit pas être modifiée (c’est-à-dire qu’il ne doit pas y avoir d’écriture) entre la lecture (partie droite de l’affectation) et l’écriture (affectation).

Un contrat avec les applications. Les garanties de cohérence font l’objet d’un contrat entre les applications distribuées et le système qui gère le partage de données. Comme détaillé au chapitre 4, ce contrat est appelémodèle de cohérence. Dans ce chapitre, nous nous concentrons sur un exemple de protocole de cohérence implémentant le modèle de cohérence à l’entrée introduit par le système à mémoire virtuellement partagée Midway [15]. Ce modèle permet d’offrir des accès aux données performants, il convient particulièrement aux applications de calcul scientifique.

5.2 Un exemple de protocole non tolérant aux fautes

Les études de la cohérence des données dans les systèmes à mémoire virtuellement par-tagée ont montré que les modèles de cohérence relâchée pouvaient être implémentés par des protocoles efficaces. En revanche, les garanties de cohérence des données sont plus res-treintes. Par exemple, les applications accédant aux données partagées doivent utiliser des opérations de synchronisation commeacquireourelease. L’opérationacquirepermet de s’assu-rer que les accès à la donnée qui suivront respecteront les garanties de cohérence. L’opération releasepermet quant à elle de garantir la propagation, éventuellement paresseuse, des mises à jours locales dans le système. Comme décrit dans la section 4.1.2, ceci est vrai pour des modèles comme la cohérence à la libération [51], la cohérence à l’entrée [15] et la cohérence de portée [61].

5.2.1 Le modèle de cohérence à l’entrée

Nous choisissons lemodèle de cohérence à l’entréepour cet exemple. Il présente la particu-larité d’associer explicitement un objet de synchronisation spécifique à chaque donnée. Cette particularité permet un gain de performance au niveau du protocole de cohérence. En effet, lorsqu’un processus entre en section critique¹pour accéder à une donnée, par exemple pour

1Une section critique correspond à une portion de code manipulant des ressources communes ne devant être accédées que par un seul processus à la fois.

lire la valeur de la donnée avant de la mettre à jour, il doit le faire via l’objet de synchroni-sation associé à cette donnée. Ainsi, sur un nœud, le protocole de cohérence n’a à garantir que la cohérence des données accédées au sein de la section critique associée. Cela permet d’éviter des mises à jour non nécessaires : seuls les processus qui déclarent qu’ils vont accé-der aux données seront concernés. De plus ne seront mises à jour que les données qui seront effectivement accédées.

Afin d’utiliser le modèle de cohérence à l’entrée, les programmeurs d’applications doivent respecter deux contraintes. Premièrement, chaque donnée partagée doit être asso-ciée à un objet de synchronisation spécifique. Deuxièmement, les accèsnon-exclusifsou en lecture seule(c’est-à-diresansmise à jour de la valeur de la donnée) doivent être distingués desaccès exclusifs(c’est-à-direavecmise à jour de la valeur de la donnée). La distinction entre les deux types d’accès est faite en utilisant des primitives différentes :acquire_readpour en-trer dans une section de code où l’on effectue des accès non-exclusifs, etacquirepour entrer dans une section critique comprenant des accès de type exclusif. Ceci permet au protocole de cohérence d’autoriser des accès concurrents en lecture : plusieurs processus peuvent accéder en lecture, de manière concurrente, à une même donnée.

5.2.2 Un protocole basé sur une copie de référence

Comme point de départ pour cet exemple, nous choisissons un protocoleimplémentant lemodèle de cohérence à l’entrée. Le protocole choisi est fondé sur la notion decopie de ré-férence(home based) associée à chaque donnée partagée. Le nœud sur lequel l’unique copie de référence est placée (home node) est également responsable de la gestion de l’objet de syn-chronisation associé à la donnée.

Lorsqu’un processus accède à la donnée, il le déclare en verrouillant l’objet de synchroni-sation par l’intermédiaire d’une des primitives de synchronisynchroni-sation :acquireouacquire_read.

Lors de l’appel à l’une de ces primitives, la copielocale, située sur le même nœud que le processus, est mise à jour si nécessaire. De la même manière, lorsque le processus quitte la section au sein de laquelle il accédait à la donnée, il relâche l’objet de synchronisation par l’intermédiaire de la primitiverelease. Si la donnée a été modifiée par le processus durant la section critique, les mises à jour locales sont alors propagées à la copie de référence.

Il apparaît donc que de nombreuses communications sont nécessaires entre les nœuds sur lesquels s’exécutent les processus accédant à une donnée partagée et le nœud hébergeant la copie de référence associée à cette donnée. La figure 5.1 illustre les communications qui ont lieu entre le nœud hébergeant la copie de référence et celui sur lequel s’exécute un processus accédant à la donnée, appelé aussinœud client.

5.2.3 Fonctionnement du protocole de cohérence

La figure 5.1 illustre le fonctionnement du protocole de cohérence lorsque les interac-tions sont limitées à un seul client. Il n’y a donc pas, dans cet exemple, de mise en attente au niveau du nœud hébergeant la copie de référence entre la réception d’une requête de syn-chronisation et l’envoi de l’autorisation d’accès : l’attente du processus client est limitée à la somme des temps de communications et du temps de traitement de la requête. Cependant, le protocole de cohérence gère aussi l’accès à une donnéepartagéeaccédée par de multiples processus potentiellement de manière concurrente. Lorsque plusieurs processus accèdent

5.2 – Un exemple de protocole non tolérant aux fautes 59

Envoi de la donnée d Noeud client Noeud hébergeant la copie de référence

Temps requête

acquire(d)

Attente

write(d) locaux

Accès

read(d)

release(d)

d

d

Mise à jour de d Attente

Mise à jour propagée

acquittement

F^IG. 5.1 – Communications entre un nœud client et un nœud hébergeant une copie de réfé-rence pour une donnéed.

de manière concurrente à la donnée le protocole met en attente certains processus afin de garantir la cohérence des accès.

Ce comportement est représenté par l’automate à états de la figure 5.2 qui décrit le fonc-tionnement simplifié du protocole de cohérence au niveau de la copie de référence. Cet au-tomate est composé de trois états principaux :NO_LOCK,ON_LOCK et ON_LOCK_R. Ils correspondent respectivement aux cas où : 1) l’objet de synchronisation associé à la donnée est libre ; 2) un processus a acquis l’objet de synchronisation en mode exclusif ; et 3) un ou plusieurs processus ont acquis l’objet de synchronisation en mode non-exclusif. En plus de ces trois états principaux, le protocole de cohérence gère trois listes : 1) L (pourLock) qui contient les identifiants des processus en attente pour un accès exclusif à la donnée ; 2)LR (pour Lock Read) qui contient les identifiants des processus en attente pour un accès non-exclusif ; et 3)OLR(pourOn Lock Read) qui contient les identifiants des processus possédant l’objet de synchronisation en mode non-exclusif. On remarque notamment que le protocole ne permet un accès exclusif qu’à un seul processus client à un moment donné. En effet, quand il se trouve dans l’étatON_LOCK, il ne redistribue pas cet accès et il ne sort de cet état qu’à la réception d’un message de relâchement de l’objet de synchronisation.

L’automate à états représenté par la figure 5.3 décrit le fonctionnement du protocole de cohérence au niveau du nœud client. A ce niveau, le protocole ne gère pas de liste. En effet, pour une donnée, le client ne communique qu’avec la copie de référence associée. Il est intéressant de remarquer que certains états (ceux grisés sur la figure) sont bloquants pour l’application. Cela permet par exemple de garantir que le processus possède bien l’objet de synchronisation associé et que la copie locale de la donnée soit bien mise à jour avant de laisser l’application accéder à la donnée.

& LR non vide

acquire_read

acquire_read acquire

acquire_read

acquire acquire

release & L vide

release &

L, LR et OLR sont des listes

NO_LOCK

ON_LOCK ON_LOCK_R

release &

L & LR vides release &

OLR & L vides

release &

L non vide

release & OLR vide

OLR vide

& L non vide

F^IG. 5.2 – Automate à états représentant le protocole de cohérence au niveau de la copie de référence.

5.2 – Un exemple de protocole non tolérant aux fautes 61

ATTENTE UNLOCK ATTENTE

LOCK

ATTENTE LOCK_R

acquire acquire_read

release release

acquitement reçu

acquitement reçu

acquitement reçu

ON_LOCK_R NO_LOCK

ON_LOCK

F^IG. 5.3 – Automate à états représentant le protocole de cohérence au niveau du nœud client.

Les états non grisés ne bloquent pas l’application alors que les états grisés correspondent à des primitives synchrones.

Le protocole décrit ici n’est pas adapté à une architecture de type grille : 1) il est centralisé autour du nœud hébergeant la copie de référence et ne prend pas en compte la topologie réseau des grilles ; 2) il ne prend pas en compte la possibilité d’apparition de fautes. Les sections suivantes détaillent ces limites et proposent des solutions pour y faire face.