Précédent : Actions de recherche Remonter : Actions de recherche Suivant : Concurrence et typage

Un modèle du calcul distribué d'ordre supérieur

  Participants : D. Doligez, C. Fournet, G. Gonthier, J.-J. Lévy, L. Maranget, D.  Rémy (projet CRISTAL )

Mots-clés : parallélisme,parallélisme asynchrone,pi-calcul,langage fonctionnel,programmation répartie,tolérance aux fautes,agents mobiles,concurrence,ramasse-miettes

Nous avons poursuivi en 1996 le développement de notre modèle formel, le join-calcul, afin d'y intégrer les primitives de distribution qui avaient été identifiées par notre groupe de travail en 1995. Nous avons ainsi défini le join-calcul distribué, qui est un des premiers calculs de processus prenant réellement en compte les problèmes liés à la répartition des calculs.

Dans le join-calcul distribué, chaque sous-processus est lié lexicalement à une location qui détermine l'endroit où il s'exécute. Le join-calcul distribué comporte de plus des primitives pour créer, déplacer, arrêter, et tester l'échec de locations.

Techniquement, le join-calcul distribué se distingue par trois innovations :

l'organisation hiérarchique de locations :

une location peut contenir d'autres locations, et ainsi de suite récursivement. On peut ainsi associer une location à chaque niveau de mobilité : une location peut aussi bien représenter un site qu'un agent, une ressource ou un objet, et l'imbrication des locations peut aussi bien représenter la situation géographique d'un agent que l'attachement de ses ressources à un agent. Enfin, la primitive de déplacement permet de modifier dynamiquement l'arbre des locations, par exemple pour faire migrer un agent ou lui rajouter de nouvelles ressources.

le controle lexical de la mobilité :

les primitives de migration et d'arrêt n'affectent que leur location lexicale. Ceci permet d'avoir un contrôle syntaxique simple de la mobilité, par exemple on peut aisément vérifier qu'une location est un site physique, c'est-à-dire qu'elle ne peut se déplacer. Cette propriété lexicale permet plus généralement d'offrir des garanties de sûreté de fonctionnement; par exemple, un serveur peut autoriser une applet à s'installer, sans lui permettre de déplacer ou fermer le serveur.

une primitive de détection d'échec :

la primitive fail permet de détecter si une location s'est arrêtée, y compris dans le cas où cet arrêt est dû à une panne du site où elle se trouve. En effet, il nous est apparu qu'il était impossible de programmer la récupération d'erreur sans détection fiable de l'échec, notamment lorsqu'on délègue des pouvoirs à un agent. Or la détection de panne est théoriquement impossible dans un modèle asynchrone comme le join-calcul, mais souvent possible en pratique, en utilisant par exemple des propriétes de temporisation, ou une hiérarchie administrative, ou toute autre méthode pour atteindre un consensus distribué. La primitive fail permet d'encapsuler ces mécanismes particuliers et de conserver la simplicité du modèle asynchrone dans le reste du modèle.

Enfin, soulignons la symétrie entre la définition de processus du join-calcul, qui réalise une liaison statique avec une portée dynamique, et la définition de locations, dont la portée est statique, mais dont les liaisons d'imbrication sont dynamiques.

Ce cadre théorique à la fois simple et rigoureux a permis une étude précise de la sémantique de l'échec. Ceci a aboutit à la définition d'une primitive de test d'échec compatible avec le calcul asynchrone, et à une formalisation des équivalences modulo échec.

Plusieurs exemples de protocoles classiques ont été modélisés dans le join-calcul distribué, afin d'en valider la puissance d'expression. Nous avons en outre étudié un protocole client-agent-serveur (CASA ) afin de démontrer l'adéquation de notre modéle aux systèmes répartis et mobiles.

Tous ces résultats ont fait l'objet d'une communication à CONCUR'96 [5].

Précédent : Actions de recherche Suivant : Concurrence et typage Remonter : Actions de recherche