INRIA Rocquencourt, le 10-12 janvier 2000
Christophe Lavarenne explique les détails du jeu de macro-instructions qui sont générées par SynDEx à partir d'une architecture et d'un algorithme donnés, ainsi que les codes C monoprocesseur et multiprocesseur générés. Il présente les différences qui existent entre SynDEx v4 et SynDEx v5 sur ces points.
Puis on discute sur les problèmes que l'implantation des heuristiques de tolérance aux pannes soulèvent. Supposons qu'on a un algorithme avec une partie dans laquelle l'opération A doit être exécutée avant B, et telle que le résultat de A est fourni à B (voir figure (a) ci-dessous). De plus, on a une architecture avec trois processeurs et deux média, décrite dans la figure (b). On veut faire une implantation de l'algorithme sur l'architecture, implantation qui est contrainte par le fait que A doit être exécuté sur P1 ou P3 et B sur P2. Enfin l'implantation doit permettre la panne de l'un des processeurs P1 ou P3.
La figure (c) représente le résultat de l'heuristique de Mihaela. Cette exécution correspond au cas où il n'y a aucune panne de processeur et où le processeur P2 ignore le résultat envoyé par le processeur P3. Ignorer peut se traduire par le fait que le coprocesseur de communication de P2 pour le média M2 est empêché de signaler le fait qu'il a recu des données. D'autre part, la manière la plus simple pour P2 de trouver quand l'un des deux processeurs P1 ou P3 tombe en panne est d'utiliser un chien de garde (watchdog) qui est armé quand P2 commence à attendre pour les données, et qui provoque une interruption quand il arrive à une valeur predéfinie afin de signaler que la communication n'a pas eu place.
Si le processeur P1 tombe en panne, alors les dates d'exécution sont modifiées ; de plus, le processeur P2 ne peut plus ignorer les données qui arrivent du processeur P3. Alors on doit décider lequel d'entre les deux coprocesseurs a le droit de signaler qu'il a reçu le premier les résultats. Cela se peut faire ou bien de manière statique, en utilisant l'implantation sans panne (c) et en donnant le droit au coprocesseur du média M2 de signaler qu'il a reçu les données seulement après que le chien de garde du coprocesseur de média M1 a signalé que la communication qu'il attendait n'a pas eu lieu, ou bien de manière dynamique, en autorisant au premier coprocesseur qui arrive à recevoir les données, de signaler ce fait, et enfin d'inhiber l'autre coprocesseur. La deuxième solution, étant symétrique, est donc plus naturelle. De plus, la première solution prolonge la durée d'exécution de chaque « boucle » de l'algorithme plus que la deuxième ne le fait.
On a discuté aussi sur la necessité d'execution non-conditionnelle de chaque duplicat des opérations du graphe algorithme. Christophe a argumenté que si l'exécution des duplicats est conditionnée, on aura un certain degré de non-determinisme, qui pourra avoir des résultats défavorables sur la sûreté de fonctionnement. Ceci contredit le principe de base de SynDEx, qui dit qu'un ordre différent d'arrivée des événements doit produire des solutions identiques (déterminisme).
On a montré la nécessité d'étudier aussi des heuristiques de tolérance aux pannes des médias de communication et des capteurs/actionneurs. Le problème se pose en effet pour le CyCab. Christophe a indiqué que dans le cas du CyCab, il n'y a pas de processeurs qui sont dédiés à faire seulement des operations. Du coup les heuristiques existentes sont de moindre intérêt. Catalin va donc procéder à une étude bibliographique sur le problème particulier de la tolérance aux pannes des médias de communication et des capteurs/actionneurs, en partant de la bibliographie que Mihaela a déjà obtenue. Catalin s'occupera également de l'étude en détail des résultats donnés par les heuristiques existentes dans quelques cas sufisamment généraux.
Du 14 au 16 février aura lieu un second séjour de travail de Catalin à Rocquencourt. Catalin y apportera les résultats de ses recherches bibliographiques pour qu'on démarre l'étude des quelques heuristiques de tolerance aux pannes des medias de communication et des capteurs/actionneurs.
Envoyez vos commentaires à Alain Girault à Alain.Girault@inrialpes.fr.
Dernière modification : 17 janvier 2000
