I.M.A.G ECOLE DOCTORALE MATHEMATIQUES ET INFORMATIQUE DEA D INFORMATIQUE: SYSTEMES ET COMMUNICATIONS. Projet présenté par. Christophe JOUBERT

Transcription

1 Université Joseph Fourier U.F.R. Informatique et Mathématiques Appliquées Institut National Polytechnique de Grenoble E.N.S.I.M.A.G. I.M.A.G ECOLE DOCTORALE MATHEMATIQUES ET INFORMATIQUE DEA D INFORMATIQUE: SYSTEMES ET COMMUNICATIONS Projet présenté par Christophe JOUBERT Techniques et outils pour la construction massivement parallèle de systèmes de transitions Effectué à l Inria Rhône-Alpes / projet Vasy Date de soutenance : 19 juin 2002 Jury : Nicolas Halbwachs François Rechenmann Yves Denneulin Hubert Garavel Radu Mateescu

2 2

3 Remerciements Je tiens à remercier : Messieurs Nicolas Halbwachs et François Rechenmann pour leur participation au jury et pour l attention qu ils ont porté à ce travail. Monsieur Yves Denneulin qui m a fait l honneur de participer à ce jury de DEA. Monsieur Hubert Garavel pour m avoir accueilli au sein du projet VASY et pour ses conseils avisés tout au long de cette année. Plus particulièrement, M. Radu Mateescu pour toutes les raisons précédentes et pour son aide constante et ses conseils sur le rapport et le DEA en général. Je le remercie pour tout le temps qu il m a consacré. Enfin, tous les membres de l équipe VASY pour la qualité et la gentillesse de leur accueil. Gordon Pace, pour ses cours intensifs de maltais au quotidien. Bruno Ondet, pour sa prédisposition naturelle et ponctuelle aux pauses-café et repas. Frédéric Tronel, pour son point de vue et sa critique argumentés quelque soit le sujet de conversation. Solofo Ramangalahy, pour m avoir permis de m exprimer pleinement au ping-pong. Frédéric Lang, pour sa sympathie et nos nombreux échanges sur le thème du monde de la recherche. Finalement, toutes les personnes, amis et famille, qui m ont permis par leur aide d effectuer ce DEA dans les meilleures conditions possibles. 3

4 4

5 Table des matières 1 Introduction La vérification formelle Les vérificateurs par modèles Problème de l explosion combinatoire Contexte du projet L équipe Vasy État d avancement des techniques développées Motivations, objectifs et contributions Organisation du document La génération distribuée d espace d états La génération séquentielle d espace d états L adaptation du parallélisme au problème Approches et composants Les mécanismes de distribution de la génération Les composants de la génération distribuée L évolution des méthodes : synthèse et discussion Les algorithmes Distributor et Coordinator Principe de fonctionnement Désignation et association des composants Architecture parallèle support Partitionnement des tâches Structures de données requises Type de communication Format de description du modèle à vérifier Terminaison distribuée Type de vérification Performances de la technique Le protocole de cohérence des termes et des labels Définition du problème Analyse de protocoles L algorithme Distributor

6 Construction de l espace d états partitionné Détection de la terminaison Détection de pannes franches Gestion des types de données dynamiques Visualisation et analyse du système L algorithme Coordinator Détection de pannes franches et d arrêts par l utilisateur Gestion des types de donnée dynamiques Visualisation et analyse du système Vérification formelle de Distributor et de Coordinator Le langage Lotos Sémantique du langage Un exemple : le protocole d exclusion mutuelle L algorithme Distributor simplifié Spécification en Lotos Vérification de propriétés en logique temporelle Extension de la spécification par l algorithme Coordinator Spécification en Lotos Vérification de propriétés d équivalence Réalisation et expérimentation L environnement Open/Cæsar Les primitives de communication Etude des limitations existantes Architecture nouvelle de communication Expérimentations La grappe de Pc de l Inria Analyses de performances Le monitoring du système Distributor Conclusion 95 A État de l art : analyse bibliographique comparative 99 B Spécification des protocoles en LOTOS 123 B.1 Structures de données B.2 Comportements des processus B.3 Propriétés temporelles Liste des figures 143 Bibliographie 145

7 Chapitre 1 Introduction 1.1 La vérification formelle Les méthodes de conception rigoureuse et de validation formelle des systèmes informatiques, aussi bien logiciels que matériels, représentent un domaine de recherche très actif à l heure actuelle. L importance de ce domaine n est plus à reconnaître lorsque l on parle d applications, dites critiques, c est-à-dire dont les défaillances peuvent avoir des conséquences dramatiques sur les hommes qui sont dans leur environnement. De tels systèmes correspondent aux logiciels embarqués dans les transports aériens, terrestres ou spatiaux, dans le domaine de l énergie ou encore celui des télécommunications, et du paiement électronique, où la moindre erreur d exécution peut prendre des dimensions très importantes : le problème du Therac-25, une machine d irradiation thérapeutique permettant le traitement des cellules cancéreuses par rayons, construite par Énergie Atomique du Canada. Bilan des défaillances du logiciel de contrôle de l appareil : 2 morts et 4 irradiés le bug du processeur Pentium d Intel, comportant une erreur dans l algorithme de division, en Coût : 500 millions de dollars l explosion du premier vol d Ariane 5, le 4 Juin Coût : 500 millions de dollars de pertes matérielles les anomalies graves dans le système de pilotage automatique des avions Bœing 747, comme la perte subite de vitesse et d altitude. Coût financier très important, mais finalement et heureusement pas de coût humain. Tous ces problèmes étaient liés à des erreurs de logiciels supposés corrects après n avoir effectué que des phases traditionnelles de tests. La sécurité des hommes et des biens d une part et la maîtrise des coûts de maintenance d autre part conduisent à accorder une attention plus grande aux questions de vérification des logiciels. 7

8 8 Chapitre 1. Introduction Le caractère critique de ces applications, dont la sûreté est le facteur le plus important à considérer, motive le besoin de développer des méthodes formelles de conception et de vérification dont le but est d assurer le fonctionnement correct de ces systèmes avant leur implantation. Toute erreur lors de leur exécution peut, comme dans les exemples ci-dessus, avoir des conséquences irréversibles, c est pourquoi on a besoin d un haut degré de sécurité et de fiabilité pour pouvoir les rendre opérationnels. Une façon de résoudre ce problème, est d abstraire, en écartant tous détails inutiles, par la conception d un modèle qui représente le système à un haut niveau. Un tel modèle abstrait devrait faire ressortir les propriétés du système qui doivent satisfaire certains critères pour que le système ait le comportement désiré. Les méthodes formelles apportent une solution à ce problème, car elles permettent de définir des modèles mathématiques décrivant rigoureusement ces systèmes. Elles les décrivent principalement à l aide de langages formels adaptés et définis précisément au niveau de la syntaxe et de la sémantique. Une fois décrit, elles peuvent prouver la correction du modèle en utilisant des méthodes de vérification formelle. La vérification consiste alors à s assurer que l ensemble des fonctionnements du système développé satisfait tous les besoins. Les principales techniques de vérification de logiciel issues des méthodes formelles se regroupent en trois classes : les assistants de preuve ou Theorem Provers, les vérificateurs par modèles ou Model Checkers et les générateurs automatiques de tests. Les assistants de preuves L approche la plus générale de vérification est de formuler les conditions de conformité d un système comme des théorèmes à démontrer, et de générer ensuite mécaniquement des preuves pour ces théorèmes en utilisant un outil dédié à ce genre de tâches. Les techniques de preuve s appuient sur des mécanismes de dérivation de formules, souvent logiques, à partir d une spécification axiomatique. Elles font partie de la classe des méthodes dites syntaxiques de preuve. Elles sont très puissantes au sens où elles traitent des systèmes à nombre d états infinis, mais elles sont indécidables dans le cas général, et par conséquent difficiles à automatiser. La preuve a posteriori et le développement certifié font partie de ces techniques de preuve. Dans ces deux cas, le mécanisme de vérification fait intervenir des preuves symboliques dans des logiques semi-décidables, la plupart du temps au travers d assistants de preuve. Ces assistants sont des outils qui permettent de vérifier qu une preuve donnée par l utilisateur est correcte et/ou de guider celui-ci à construire une preuve. Parmi les assistants de preuve les plus utilisés pour la vérification de logiciels sécuritaires, on peut retenir l outil Pvs (Prototype Verification System) [ORS92] du SRI International Computer Science Laboratory, l assistant de preuve Coq [DFH + 93] de l INRIA et le prouveur de théorème Isabelle [NPW02] du Cambridge Automated Reasoning Group. Les vérificateurs par modèles Une technique de vérification particulièrement attractive du point de vue coût-performance est celle basée sur les modèles. Dans cette approche, l application à traiter est d abord spécifiée dans un langage de haut niveau tel que Lotos. Cette spécification est ensuite traduite vers un modèle, comme un graphe d états ou un automate, sur lequel les propriétés attendues du système, exprimées dans un formalisme approprié, tel que les logiques temporelles ou les automates observateurs, sont vérifiées au moyen d outils spécialisés. Le model-checking [CGP00], nom donné à cette méthode, est une

9 1.1. La vérification formelle 9 technique qui permet, contrairement aux assistants de preuve, l automatisation de la preuve de correction de systèmes par rapport à des exigences spécifiées à l aide de formalisme. Les techniques de vérification par modèles sont fondées sur des algorithmes de parcours d automates. Le but est de vérifier que le modèle, représentant le système, respecte bien les spécifications, d où le terme model-checking. Ces techniques font partie des méthodes dites sémantiques de vérification. Bien que ces techniques soient limitées aux systèmes à nombre fini d états, elles permettent une détection rapide et économique des erreurs dans des systèmes complexes. Parmi les model-checkers les plus utilisés, on peut retenir Spin [Hol97], développé au sein des laboratoires Bell, Smv [CCGR00] de Carnegie Mellon University, Murϕ [MDI92] de Stanford, et Cadp [FGK + 96] développé conjointement par le projet Vasy de l Inria et le laboratoire Verimag. Les générateurs de tests Les techniques de test consistent à extraire de la spécification de référence des tests exécutables par le programme en cours d analyse, à partir de critères de sélection. La génération de ces tests peut être automatisée et conduire à un ensemble de tests exhaustifs. La validation par des jeux de tests est une phase nécessaire sinon obligatoire dans la vérification formelle d un système, car il arrive souvent qu un bon nombre de propriétés du système ne peuvent être modélisées dans les formalismes des deux méthodes précédentes. Tgv (Test Generation with Verification technology) [FJJ + 97] du projet Pampa et Vasy de l Inria et du laboratoire Verimag, fait partie de ces outils. Il utilise des techniques de vérification formelle pour la génération efficace et automatique de suites de tests de conformité. Il est important de noter dès à présent que les preuves, qui résultent des méthodes de vérification formelle, ne sauraient être en aucun cas totales. La vérification d un système doit prendre en compte l environnement dans lequel celui-ci est introduit, ce qui se traduit par l établissement d un ensemble d hypothèses. La preuve ne peut être alors que partielle puisque le processus de vérification doit considérer et utiliser les hypothèses pour prouver la justesse du système et que l ensemble des hypothèses peut varier selon les interprétations des besoins. D une part, les propriétés formalisées ne couvrent pas nécessairement la totalité des besoins, d autre part il n est pas exclu d avoir mal interprété les besoins à la fois dans les propriétés et le système. Une idée reçue est que l utilisation des méthodes formelles produit un logiciel parfait, ce qui est en partie erroné, puisqu une spécification formelle est un modèle du monde réel et peut donc inclure des erreurs, des omissions et des malentendus. Une solution parmi d autres serait de considérer l hétérogénéité des langages de spécification pour augmenter le pouvoir d expression et combiner l efficacité des méthodes de vérification Les vérificateurs par modèles Nous nous intéressons ici plus particulièrement à la méthode de vérification par modèles, qui est directement liée à notre travail. Le model-checking est une méthode de vérification ayant été utilisée avec succès dans un

10 10 Chapitre 1. Introduction grand nombre d études de cas. Elle est, comme énoncée précédemment, basée sur une analyse d accessibilité, analyse réalisée par une exploration de l ensemble des états accessibles, appelé plus communément espace d états, d un modèle abstrait à vérifier. Elle permet de détecter automatiquement des erreurs tôt dans le processus de conception de systèmes à nombre finis d états. Le fonctionnement du model-checking est la construction d un modèle, en l occurrence l espace d états, d un système en cours de conception, sur lequel les propriétés de correction désirées, spécifiées comme formules de logique temporelle, sont vérifiées. Le modèle checker est donc composé d un générateur d états et d un vérificateur de propriétés. La figure 1.1 donne une représentation simplifiée du principe de model-checking. Le générateur d états est associé à un langage de spécification et produit le graphe entier d états d un modèle décrit dans ce langage. Le model checker peut alors contrôler l exploration du graphe d états à travers le générateur d états tout en vérifiant qu il représente bien un modèle répondant aux formules logiques temporelles spécifiées. Un état possible est déterminé par l instanciation des variables d état dans leurs domaines de valeurs respectifs. Cette description implique souvent une représentation dynamique, et donc la prise en compte du temps et de l évolution. La dénomination état correspond à un instantané du modèle à un instant donné. La notion même d état fait référence au mécanisme de succession d états consécutifs indexés par un paramètre temps. programme propriété compilateur modèle model-checker oui/non + diagnostic Figure 1.1: Le principe de la vérification par model-checking Pour faire de la vérification formelle par modèle, il faut spécifier deux entités : le programme que l on veut vérifier ou plus exactement le modèle lui correspondant dans un format vérifiable, et les propriétés qu il doit satisfaire. Classification des approches Une classification possible des méthodes de vérification par modèles est basée sur trois critères : le choix du formalisme pour représenter le modèle, le type de propriétés à vérifier et l approche pour la vérification de ces propriétés.

11 1.1. La vérification formelle 11 Modèle du programme Le modèle du système que l on souhaite vérifier se fait généralement à l aide d automates, finis ou non, c est à dire de systèmes de transitions entre des états étiquetés par certaines propriétés, comme les structures de Kripke, ou à l aide d automates dont les transitions sont étiquetées, tels que les Systèmes de Transitions Étiquetées ou Ste. Spécification de la propriété Pour spécifier le critère qu un modèle doit satisfaire, on a besoin d un raisonnement sur l ordonnancement des événements, ou états, dans le modèle. Par exemple, une propriété d un réseau de communication pourrait être que lorsqu un message est envoyé, il sera finalement délivré. Le problème de la spécification est qu il faut exprimer formellement une propriété que l on exprime initialement en langage courant. La logique temporelle est excellente pour exprimer une telle succession d actions des systèmes sans introduire explicitement le temps [MP92]. Deux catégories connues de logique temporelle sont la logique temporelle arborescente, dans laquelle fait par exemple partie la logique Ctl (Computation Tree Logic) [CES86], et qui permet de quantifier les chemins des exécutions possibles que l on considère, et la logique temporelle linéaire, contenant par exemple la logique Ltl (Linear Temporal Logic) [MP92], décrivant la succession d états sur chaque séquence d exécution du système. Les types de propriétés temporelles qui sont spécifiées pour les systèmes peuvent être divisés en deux catégories principales, à savoir les propriétés de sûreté et les propriétés de vivacité. Une propriété de sûreté déclare que quelque chose de mauvais n arrivera jamais. Par exemple, un état de violation de l exclusion mutuelle entre deux processus ne sera jamais atteint dans le système lors de son exécution. Une propriété de vivacité déclare que quelque chose de bon arrivera certainement dans le futur. Par exemple, le message envoyé d un côté sera finalement délivré de l autre côté d un réseau d interconnection. Approches de vérification Il y a essentiellement deux approches pour la vérification par modèles : la vérification symbolique représente l espace d états dans sa globalité, en utilisant des techniques diverses d encodage (comme les Bdd), et la vérification énumérative représente l espace d états de manière extensive, en énumérant tous les états accessibles. Les techniques de vérification énumérative par modèles peuvent être encore divisées en techniques globales, qui requièrent de construire entièrement l espace d états avant d effectuer la vérification, et en techniques à la volée, ou encore on the fly, qui permettent de construire l espace d états simultanément avec la vérification. Langages et outils développés La diversité des applications et des besoins nécessite un pouvoir d expression très étendu. C est sur ce point que les problèmes scientifiques surgissent, car : soit les langages d expression des propriétés et des systèmes sont peu expressifs, ce qui limite les applications potentielles

12 12 Chapitre 1. Introduction soit ils sont très expressifs et la vérification est trop complexe, voire indécidable, et il n est plus possible d automatiser la méthode La question cruciale est donc de concilier les deux objectifs contradictoires : expressivité des langages et faible complexité de la vérification. Il existe deux grandes classes de méthodes formelles : les spécifications orientées propriétés et celles orientées modèles. Les spécifications orientées propriétés consistent en une description donnée dans un langage permettant d énoncer les propriétés attendues d un système, tels que la logique et plus particulièrement la logique temporelle, ou encore les types abstraits algébriques. Les spécifications orientées modèles sont basées sur la construction d un système à partir de modèles fondamentaux, comme les réseaux de Pétri ou les algèbres de processus. Ces deux approches sont ciblées sur des classes d applications pour limiter l expressivité des langages et savoir outiller la méthode : les langages dérivés de la logique classique pour exprimer des systèmes transformationnels les logiques temporelles pour exprimer des propriétés dynamiques de sûreté et de vivacité des systèmes réactifs, comme Ltl, Ctl ou Xtl [MG98], etc. les langages logico-ensemblistes comme Z [Spi92], Vdm [Jon86] et B [Abr96], basés sur la théorie des ensembles et les systèmes pré et post conditions, pour décrire et vérifier des propriétés statiques sur les états des systèmes les langages basés sur les algèbres de processus et les types abstraits algébriques, pour modéliser des systèmes concurrents avec ou sans partage de variable, comme Lotos [ISO89] (Language of Temporal Ordering Specification), Ccs [Mil89], Csp [BHR84], Esterel [BdS91], etc les réseaux de Pétri, les automates communiquants, comme Murphi [MDI92], Promela [Hol91], Estelle [ISO88], etc. les automates temporisés pour modéliser des systèmes temps réels De nombreux model-checker utilisant les langages formels cités précédemment, ont fait et/ou font actuellement l objet de recherches actives. Ils sont largement utilisés au niveau mondial dans de nombreuses entreprises ou laboratoires de recherche qui souhaitent s appuyer sur des travaux existants pour ne pas avoir à développer entièrement l outil de vérification. Parmi les plus utilisés, on peut dénombrer : SPIN Spin (Simple Promela INterpreter) [Hol97] est un système de vérification automatique de propriétés Ltl pour les protocoles écrits dans le langage de spécification Promela, tandis que le modèle sémantique est basé sur les automates finis. Promela (PROcess MEta LAnguage) est un langage non-déterministe à sections protégées basé sur les travaux de

13 1.1. La vérification formelle 13 Hoare. Promela a une syntaxe proche du langage C et permet de définir un ensemble de processus asynchrones qui interagissent au travers de variables partagées ou de canaux de communication. Spin met en œuvre des algorithmes pour vérifier à la volée les deadlocks, les portions de codes inutilisables ainsi que la brisure des assertions définies par l utilisateur. En plus, des techniques de réductions par ordre partiel sont utilisées pour diminuer la partie de l explosion combinatoire issue des différents entrelacements entre les processus concurrents lors de l exploration de l espace d états. SMV Smv (Symbolic Model Verifier) [CCGR00] est un outil pour vérifier les systèmes d états finis pour lesquels ont été spécifiées des propriétés dans la logique temporelle Ctl. Il supporte un langage de spécification flexible pouvant aussi bien décrire des systèmes à états finis synchrones que asynchrones, et utilise un algorithme de model-checking symbolique basé sur Obdd, pour vérifier efficacement si les spécifications Ctl, comme la sûreté, la vivacité ou les deadlocks, sont satisfaites par le système. MURPHI Murϕ [Dil96] est tout d abord le nom d un langage de description basé sur une collection de commandes gardées, avec des règles condition/action, qui s exécutent de manière répétée dans une boucle infinie. C est également le nom d un vérificateur formel, basé sur une énumération explicite des états. La version basique du vérificateur Murϕ comprend la réduction par symétries, les ensembles multiples, la compression par hachage, appelée aussi hash compaction, en plus de la vérification de propriétés de vivacité et des spécifications écrites dans un sous-ensemble de Ltl. CADP Cadp (Caesar-Aldébaran Development Package) [FGK + 96] est un outil de vérification pour protocoles de communication et pour systèmes distribués. Toutes les techniques intégrées à cet outil permettent de comparer une représentation explicite ou implicite de la relation de transition d un programme, à différents types de spécifications. En particulier Cadp a des méthodes efficaces de décision pour la comparaison modulo différentes relations d équivalence ou de pré ordre de modèles, telles que la bisimulation faible et forte, la bisimulation de branchement, l équivalence observationnelle, etc. Ces relations sont basées sur des critères d abstraction et peuvent être utilisées pour du raisonnement compositionnel. Cadp accepte les spécifications de haut niveau comme Lotos [ISO89], Sdl [CCI88], Uml [BJR96], ou d autres. Cette boîte à outils supporte également les formats intermédiaires comme les réseaux d automates communiquants, ainsi que les spécifications de bas niveau en terme de Ste, comme le format compact Bcg (Binary Coded Graphs). Les fonctionnalités offertes incluent une simulation intéractive ou aléatoire des modèles, la détection partielle ou exhaustive de deadlock, la vérification de spécifications comportementales ou en logique temporelle de type branching-time dans la logique Xtl (executable Temporal Language) [MG98]. La vérification à la volée est permise, et la minimisation de l espace d états est supportée en respectant plusieurs relations d équivalence.

14 14 Chapitre 1. Introduction Problème de l explosion combinatoire Dans notre travail de recherche, nous nous focalisons sur la vérification énumérative par modèles, laquelle est bien adaptée aux systèmes asynchrones non-déterministes, contenant des types de données complexes tels que les structures, ensembles, listes, arbres, graphes, etc. Les systèmes asynchrones sont utilisés pour une large mesure dans le domaine des réseaux, des systèmes et algorithmes distribués, alors que les systèmes synchrones sont quant à eux plus adaptés aux circuits matériels et aux contrôleurs embarqués. Les méthodes de model-checking font partie de la catégorie de vérification basée sur des machines à états finis (Finit State Machine (Fsm)). Elles requièrent une exploration exhaustive de l espace des configurations, ou états, du modèle. Plus précisément, nous considérons le problème de la construction du Ste, appelé également Lts pour Labelled Transition System, qui est le modèle naturel pour les langages de spécification de haut niveau, basés sur actions, notamment des algèbres de processus comme Ccs [Mil89], Csp [BHR84], Acp [BK84] ou Lotos [ISO89]. C est un graphe contenant, via certaines abstractions, tous les comportements possibles de l application. Un Ste est construit en explorant les relations de transition en partant d un état, ou comportement, initial. Pendant cette opération tous les états doivent être gardés en mémoire pour éviter les explorations multiples d un même état. Une fois le Ste construit, il peut être utilisé comme une entrée à de nombreuses procédures de vérification, tels que la vérification par bisimulation ou par pré ordre, et la vérification par logiques temporelles. La limitation essentielle des techniques de vérification énumérative par modèles est due à la taille du modèle du système ou Ste qui croît exponentiellement en fonction du nombre de composantes parallèles présentes dans le modèle. Un exemple simple montre parfaitement cette complexité. Un système de 10 processus mis en parallèle, chacun ayant seulement 10 états, a un espace d états total pouvant atteindre états. Sachant que la plupart des model checkers ne peuvent vérifier que des modèles ayant un espace d états de l ordre du million d états, il est clair que les systèmes larges et complexes ne peuvent être analysés. La raison principale d une telle limitation est que la construction de l espace d états peut être très demandante à la fois en terme de mémoire, notamment pour le stockage des données caractérisant les états, et de temps d exécution : il s agit du problème général appelé explosion des états. On peut séparer ce problème en deux sous problèmes : l explosion de la mémoire due aux données à stocker en mémoire, et l explosion du temps de calcul due aux structures de données utilisées et manipulées par les calculs. C est ce besoin d explorer exhaustivement le Ste qui provoque, dans le cas des systèmes de grande taille, le problème d explosion d états, principale limitation de l usage des méthodes énumératives de model-checking. Même après que le protocole ait été modélisé, et les propriétés en logique temporelle exprimées, la vérification effective reste encore un problème difficile, dont la complexité dépend de la taille du modèle et de la propriété à vérifier. Il y a deux façons de répondre au problème de l explosion de l espace d états : la première

15 1.1. La vérification formelle 15 est l évitement par l utilisation de méthodes de réduction de l espace d états. Cependant, cela peut conduire à ne traiter qu une classe restreinte de propriétés sur l application. La seconde est de tolérer la taille de l espace d états soit en limitant les calculs à des données relevantes pour les valeurs de sortie requises, soit en réduisant la complexité au niveau du modèle, ou soit paralléliser le processus. Durant la dizaine d années passées, différentes techniques pour contrôler l explosion des états ont été proposées, parmi lesquelles les ordres partiels et les symétries. Cependant, pour des systèmes à l échelle industrielle, ces optimisations ne sont pas toujours suffisantes, et elles sont, pour la majorité, séquentielles et donc limitées en temps d exécution et en quantité de mémoire accessible car utilisant une seule machine. Le problème de l explosion de l espace d états est décrit par les relations exponentielles qui lient le nombre d états d un modèle de système avec le nombre de composants à partir desquels les états sont déterminés. Le principal objectif pour pallier à ce problème est de diviser les méthodes et les structures de données nécessaires à la génération de l espace d états. Avec la venue de nouvelles approches sur le model-checking et d améliorations au niveau matériel, la taille des systèmes pouvant être vérifiés a considérablement augmentée. Approche symbolique Depuis quelques années, des améliorations significatives dans les techniques de représentation de modèles ont pris place et un système peut maintenant être vérifié en utilisant une mémoire beaucoup plus petite qu il était le cas avant, pour les mêmes systèmes. Une amélioration proposée par McMillan et utilisée dans Smv [CCGR00] est de ne pas représenter explicitement les états du modèle, mais d utiliser des diagrammes de décision binaires (Bdd) simples, ou des Bdd ordonnés et réduits (Robdd). Cette technique est connue sous le nom de symbolic model checking du fait que des variables symboliques sont utilisées pour représenter les états du système au lieu des variables numériques. Cette approche est particulièrement efficace pour les systèmes à structure régulière comme les circuits matériels. Bien que l emploi du Robdd pour explorer implicitement l espace des états, ait élargi le domaine d application de l approche model-checking, cette dernière demeure inadéquate pour la vérification d espace d états à grand chemin de données, car une variable individuelle est nécessaire pour chaque bit d une donnée, et donc le problème d explosion d états persiste encore. Réduction par ordre partiel et par symétries Des approches pour contrer l explosion d états font appel à la méthode de réduction, qui consiste à réduire la taille de l espace d état exploré, grâce à un certain nombre de structures redondantes utilisées pour des propriétés fréquemment recherchées. Le but est de transformer le problème de vérification du système global en un problème équivalent sur un plus petit espace d état. Une de ces techniques est connue sous le nom de réduction d ordres partiels [Val90] ou partial order reduction. Elle évite la génération de certains entrelacements d actions produits par des transitions causalement indépendantes. L autre technique est la réduction par symétries [Dil96]. Elle exploite la répétition de structures similaires souvent rencontrées dans les systèmes répartis, comme par exemple, la présence de plusieurs processus parallèles identiques qui ne différent

16 16 Chapitre 1. Introduction que par les valeurs de leurs paramètres. Les techniques de réduction consistent à construire une abstraction de l espace d états du programme, une partie relativement réduite du modèle, tout en préservant la capacité de vérifier les propriétés intéressantes. Réduction par minimisation compositionnelle D autres approches sont basées sur des techniques de vérification d un système composante par composante, ou vérification compositionnelle [AW91]. L idée est de supposer que les autres composantes se comportent correctement et de déduire que la composante analysée est correcte. Si l on fait cela pour toutes les composantes, on peut conclure que le système complet est correct sans avoir à le construire entièrement (méthode dite assume-guarantee). Le raisonnement compositionnel est basé sur l identification des propriétés locales des sous-systèmes, garantissant globalement les propriétés spécifiées pour le système. Une de ces techniques est appelée réduction par minimisation compositionnelle, et consiste en une simplification intermédiaire des soussystèmes. Ainsi, le graphe d état global n a pas besoin d être exploré, si les propriétés extraites des sous-systèmes peuvent être vérifiées à la place. Un des inconvénients de cette méthode est qu elle fait généralement baser les propriétés des sous-systèmes sur beaucoup trop de conditions spécifiques à l environnement du système. De plus, c est une tâche compliquée et non automatisable à ce jour que de décomposer et de prouver les propriétés d un système global en propriétés globales de ses composants. Vérification à la volée Comme énoncée précédemment, la vérification à la volée, ou on the fly, consiste à vérifier le modèle durant sa génération. Pour ce faire, on simule toutes les séquences de transition possibles par un parcours, en général, en profondeur d abord sans stocker les transitions. La recherche s arrête dès qu une erreur a été détectée ou lorsque le graphe entier a été exploré. Cependant le temps nécessaire pour effectuer la vérification est la plupart du temps trop élevé du fait de la regénération d états déjà visités. Dans le cas de la construction de Ste le contenu des états, rendu abstrait dans les techniques énumératives globales, doit au contraire être gardé explicitement en mémoire pour la vérification à la volée. Un autre inconvénient de la méthode est alors que la consommation mémoire est beaucoup trop élevée par l utilisation de cette technique. Parallélisation de la vérification Une approche qui n a pas encore reçu une attention significative est la parallélisation d algorithmes de model-checking. Une raison pour cela est que le genre de calculs connus pour être efficacement parallélisé, spécialement sur des machines multiprocesseurs, ont une nature régulière alors que le model-checking utilise des graphes d états qui ont une nature hautement irrégulière. D autres raisons sont que les chercheurs peuvent faire des progrès plus rapidement avec le genre de techniques mentionnées dans les paragraphes précédents qu avec la parallélisation, à cause de sa difficulté inhérente, et aussi à cause d une accessibilité réduite à des machines parallèles comparés à celle de machines à un processeur, principalement pour des raisons de différence de coût. Pourtant le model-checking parallèle a de nombreux avantages.

17 1.2. Contexte du projet 17 Afin de ne pas établir de limitations sur les calculs pour un certain type de donnée, limitations par exemple présentes dans les méthodes de réduction de complexité au niveau du modèle formalisé, la parallélisation de l analyse utilise la puissance de calcul et les ressources des machines parallèles. Une solution pour palier au problème de l explosion combinatoire consiste donc à utiliser non pas un seul ordinateur, mais un ensemble d ordinateurs reliés entre eux par un réseau, ce qui permet d avoir accès à l ensemble des ressources mémoires et processeurs de ces ordinateurs. Une autre approche consiste à utiliser des machines parallèles multiprocesseurs, appelées supercalculateurs pour, de manière équivalente, faire usage de plusieurs processeurs pour le calcul et d une capacité de stockage non présente sur les machines monoprocesseur. Bien que la parallélisation du processus de génération de l espace d états soit un problème non trivial, il représente un moyen approprié pour réduire le temps dépensé durant l analyse, et pour résoudre des modèles dont la taille est agrandie par un ordre de complexité comparé à ceux résolus séquentiellement. De plus, la parallélisation peut être utilisée en conjonction avec quelques unes des autres techniques développées pour combattre le problème de l explosion d états. Le travail de recherche de ce Dea est axé autour de la technique de parallélisation de la vérification. Nous y définissons une approche possible, qui vise à combattre l explosion combinatoire de l espace d états, fondée sur l utilisation du parallélisme au sein de la génération de l espace d états, et sur la puissance de calcul de réseaux ou de grappes de stations de travail. 1.2 Contexte du projet L équipe Vasy Le travail effectué, s inscrit dans le cadre du projet Vasy (VAlidation de SYstèmes) de l Institut National de Recherche en Informatique et Automatique (Inria). Les travaux du projet Vasy sont situés dans le domaine des méthodes formelles appliquées aux systèmes critiques. Parmi les activités de recherche du projet Vasy se trouvent les langages formels de spécification et les méthodes et outils associés, la compilation et le prototypage rapide, la simulation et la vérification, et enfin la génération de cas de tests. Les méthodes et outils développés par l équipe Vasy sont appliqués aux études de systèmes réels, comme les architectures multiprocesseurs, les bases de données distribuées, les systèmes de fichiers distribués, les protocoles de communication, et de sécurité, les systèmes embarqués ou répartis, etc. Ce projet développe, en collaboration avec d autres partenaires, une boîte à outils très performante, appelée Cadp [FGK + 96], qui offre un éventail complet de fonctionnalités pour l ingénierie des protocoles et des systèmes distribués.

18 18 Chapitre 1. Introduction État d avancement des techniques développées En 1999, des travaux ont été entrepris pour améliorer les performances des algorithmes de vérification énumérative par l utilisation de machines parallèles et fut l objet du travail postdoctoral d Irina Smarandache. En effet, ces algorithmes nécessitent l exploration exhaustive et le stockage de graphes de dimensions importantes, de l ordre du million d états. Ils sont souvent limités par la puissance de calcul et l espace mémoire disponible sur les machines séquentielles actuelles. C est pourquoi il était désirable de repousser ces limites en exploitant au mieux les possibilités des machines parallèles de type Mimd à mémoire distribuée, comme les grappes de Pc ou les réseaux de stations de travail, disponibles dans les laboratoires de recherche. Les efforts se sont concentrés sur la parallélisation de l algorithme de construction du graphe d états, qui constitue un goulot d étranglement pour la vérification puisqu il requiert un espace mémoire considérable pour stocker tous les états accessibles. La parallélisation de cet algorithme a permis, en remplaçant la mémoire d une seule machine par celles de dizaines ou de centaines de machines, de gagner plusieurs ordres de grandeur dans la complexité des graphes traités. Ce travail a donné lieu à une publication [GMS01]. En 2000, les méthodes développées ont abouti au développement de deux outils prototypes : Distributor 1.0, qui répartit la construction d un graphe sur N machines communiquant deux à deux au moyen de sockets. Chaque machine est chargée de construire une partie du graphe sous forme d un fichier au format Bcg, les états étant répartis entre les mémoires locales des machines au moyen d une fonction de hachage déterminée statiquement. Bcg Merge 1.0, qui assemble les N parties de graphe construites sur chaque machine par Distributor afin d obtenir un fichier Bcg unique représentant le graphe complet dans une représentation compacte. Ces travaux ont été poursuivis en 2001 pour augmenter les performances, la robustesse et l ergonomie des outils. L outil a été revu et réécrit par Adrian Curic lors d un travail de Dea, notamment pour permettre aux communications de ne plus être basées sur des sockets bloquantes, pour introduire un processus auxiliaire chargé de lancer la construction distribuée ainsi que du lancement de l outil Bcg Merge à la fin de la génération, et pour utiliser des fichiers de configuration contenant l ensemble des paramètres nécessaires à la génération distribuée. Gilles Stragier, étudiant en 4ème année de l Université de Bruxelles en Belgique, a contribué à la robustesse de l outil Distributor, par la mise en place de la détection des arrêts anormaux durant la génération distribuée, et des interfaces avec l utilisateur, essentiellement grâce à un outil de suivi en temps réel de la progression de la génération distribuée. D une part, les travaux précédents ont tous été plus axés pratique que théorique, privilégiant l implantation rapide d un prototype à celle de la mise en place justifiée et prouvée d algorithmes représentatifs de l outil. Les avancées, au niveau expérimentation et résultats, ont, certes, été importants, mais pour parfaire la méthode, il lui manque toujours les fonde-

19 1.3. Organisation du document 19 ments théoriques naturels à toute nouvelle méthode. D autre part, l outil était sévèrement limité par une mauvaise gestion de l espace mémoire, par la taille du graphe à générer, et par le passage à l échelle de la méthode, notamment à cause de l utilisation d un mécanisme inefficace de communication, brique de base du parallélisme par passage de message Motivations, objectifs et contributions Notre travail s inscrit dans un double contexte : d une part, une contribution à la révision des techniques et algorithmes distribués mis en œuvre dans les versions précédentes de Distributor, et, d autre part, le développement de méthode nouvelle et outil pour le traitement, par Distributor, de spécifications formelles contenant des types de données dynamiques, tels que les listes, arbres, etc. L étude des différents outils de model-checking mentionnés dans les sections précédentes, nous a permis de préciser les choix de conception appropriés pour un générateur distribué d espace d états tel que Distributor. Un premier axe de notre travail porta sur la définition des composants primordiaux de cet outil. Chaque composant représentant un critère de performance pour l outil dans sa globalité, leur utilisation combinée a nécessité une analyse portée sur l efficacité, la portabilité et le passage à l échelle de la méthode, ainsi que sur le coût en temps de calcul et la gestion efficace de l espace mémoire dans différents environnements d expérimentation parallèles. Notre travail a abouti à l établissement d un algorithme distribué respectant ces critères, que nous avons vérifié formellement à l aide du langage Lotos et de la boîte à outils Cadp. Un deuxième axe de notre travail a visé à concevoir un nouveau composant théorique et logiciel pour permettre à Distributor de traiter les spécifications contenant des types de données dynamiques, tels que les listes, arbres et ensembles, qui sont fréquemment présents dans les applications distribuées complexes, comme les protocoles de cohérence de cache. Plusieurs schémas de gestion de termes ont été étudiés, notamment concernant la représentation des termes pour transmission sur le réseau, et l utilisation d un serveur de termes centralisé ou distribué. Pour ce développement d outil, et pour la modification de Distributor, nous avons tiré partie de l environnement générique Open/Cæsar[Gar98] de Cadp. 1.3 Organisation du document Nous présentons ici l organisation du document. Elle reflète les différents axes du travail effectué. Le chapitre 2 présente un état de l art complet de la génération distribuée d espaces d états, avec une étude comparative des techniques développées jusqu à présent dans le contexte de la vérification formelle énumérative par modèles.

20 20 Chapitre 1. Introduction Le chapitre 3 présente la solution que nous avons choisie et étudie la technique mise en place dans l outil Distributor pour gérer les types de données dynamiques. Le chapitre 4 aborde la vérification formelle des algorithmes proposés précédemment, au moyen de Lotos et de la boîte à outils Cadp. Le chapitre 5 est consacré à la réalisation et aux expérimentations sur des applications complexes pour lesquelles une simulation exhaustive sur une machine séquentielle est très coûteuse. L annexe A contient une matrice comparative de l état de l art sur l introduction du parallélisme dans la génération de l espace d états d une part, mais également des divers outils de vérification parallèle par modèles d autre part. L annexe B présente les spécifications Lotos complètes de l outil Distributor, notamment les structures de données manipulées, les protocoles mis en œuvre et les propriétés vérifiées sur les spécifications formelles.

21 Chapitre 2 La génération distribuée d espace d états Ce chapitre se propose de faire un état de l art complet sur les travaux de recherche concernant la génération parallèle des espaces d états, ou graphes, à partir de différents langages. De nombreux travaux ont été publiés sur la génération parallèle de graphes d états pour les réseaux de Pétri et les chaînes de Markov, et, plus récemment, pour des langages de spécification formelle de plus haut niveau comme Murphi et Promela. La section 2.1 contient une brève présentation de la génération d espace d états d un point de vue séquentiel et la section 2.2 introduit progressivement la notion de parallélisme. Toutes les approches existantes seront présentées en section 2.3, où nous identifierons leurs avantages et inconvénients respectifs. La section 2.4 fera une synthèse de ces approches afin de dégager les principes applicables dans le contexte de notre travail. 2.1 La génération séquentielle d espace d états Dans le cadre de la vérification énumérative par modèles, lorsque l on construit des modèles de systèmes complexes, il est essentiel de représenter tous les états globaux, ou configurations à des instants donnés, du système, en ne considérant seulement que les états locaux, c est à dire les états des sous-composants de ce système. Cette approche mène à une description et une représentation très compacte de l information contenue dans le modèle. Cependant, pour obtenir des réponses détaillées sur l occurrence et sur les interdépendances des événements et du comportement du système dans sa globalité, il est nécessaire que tous les états globaux soient disponibles lors du processus d analyse. Cela veut dire que l espace d états de l application, représenté par l ensemble de tous les états globaux et des transitions possibles entre eux, doit être généré préalablement à la phase de vérification des propriétés sur ce système. Mathématiquement, l espace d états peut être formalisé comme étant un graphe. Les nœuds du graphe constituent les états globaux du système, et les arcs représentent les transitions 21

22 22 Chapitre 2. La génération distribuée d espace d états entre ces états. Dans la littérature, il est d ailleurs couramment appelé graphe d accessibilité. Pour construire un tel espace d états, il faut donc d abord définir les notions d état global et d état local. La définition d un état global et d un état local est intimement lié au formalisme utilisé lors de la description de l application. Dans le cas des réseaux de Pétri stochastiques généralisés (Gspn), les marques, ou markings, c est à dire les dispositions possibles des jetons sur l ensemble du réseau de Pétri, et les places, ou positions des jetons, représentent respectivement les états globaux et les états locaux du système modélisé sous forme de réseau de Pétri. Pour des formalismes de plus haut niveau, comme avec le langage Lotos, l état global est représenté par un vecteur de valeurs, et ces valeurs, par exemple des données, représentent les états locaux. L algorithme, permettant la génération de l espace complet d états, ressemble à ceux d autres techniques d énumération d espace d états, comme la méthode du Branch and Bound utilisée pour la solution de problèmes combinatoires tels que les problèmes de jeu d échec par ordinateur ou encore celui du voyageur de commerce, appelé travelling salesman. Cependant, la principale différence est que le résultat du calcul n est pas une seule valeur, comme la longueur du chemin minimal dans le problème du voyageur de commerce ou l évaluation d une position dans un jeu de stratégie, mais la totalité de l espace d états lui-même. C est pourquoi, aucune coupure ne peut être effectuée sur le graphe car l espace d états complet doit être généré. Des algorithmes séquentiels performants ont été décrits dans la littérature. La figure 2.1 présente un algorithme séquentiel respectant la structure générale communément utilisée. Cette structure se découpe en trois étapes répétées jusqu à terminaison au sein d une itération. procedure Generator (in s 0, succ; out T) is E := ; V := {s 0 }; T := while ( s in V ) do V := V \ {s} foreach (s,a,s ) in succ(s) do if s E V then V := V {s } endif T := T (s,a,s ) endfor E := E {s} endwhile end Figure 2.1: Génération séquentielle d un espace d états sous forme de système de transitions étiquetées (Ste) La génération commence par le traitement de l état initial s 0, connu explicitement avant le début du processus. Ensuite s ensuit une phase au cours de laquelle on construit pro-

23 2.2. L adaptation du parallélisme au problème 23 gressivement deux ensembles d états : l ensemble des états E, pour Explorés, dont tous les successeurs ont été générés, et l ensemble des états V, pour Visités, dont les successeurs n ont pas encore été générés. Le premier représente, en fait, la construction progressive de l espace d états, états pour lesquels on connaît tous les états successeurs. Quant au deuxième ensemble, il n est que temporairement utilisé pour la partie manquante de l espace d états, c est à dire les états non encore explorés, et se vide progressivement. A tout instant, l union des deux ensembles E et V forme le graphe d accessibilité jusqu alors construit. Parallèlement, on construit l ensemble T des transitions de l espace d états dès qu une nouvelle transition est découverte. Une transition (s,a,s ) indique que le système peut passer de l état s à l état d arrivée s en exécutant l action a. Les trois grandes phases de la génération sont donc : une phase d extraction d un état de l ensemble des états non explorés, une phase de génération de ses successeurs par exécution de transitions, et une phase de recherche et d insertion des états et transitions générés dans les ensembles appropriés. La terminaison est détectée lorsque l on ne peut plus ajouter d états à l ensemble des états générés, c est à dire lorsque l ensemble V est vide. 2.2 L adaptation du parallélisme au problème Les modèles des applications réelles tendent à être de très larges espaces d états. La vérification de ces modèles en est affectée, car la génération de l espace d états consomme la majeure partie du temps de calcul nécessaire au processus d analyse du modèle. Ajouter à cela, les espaces d états résultants de la génération sont souvent trop larges pour pouvoir tenir dans la mémoire principale d une seule machine. La parallélisation de la génération de l espace d états sur un ensemble de processeurs apparaît donc comme une suite naturelle des techniques développées séquentiellement jusque là. L évolution des machines est telle que les machines multiprocesseurs à mémoire partagée deviennent beaucoup plus courantes à notre époque, et les nombreuses machines reliées par réseaux et présentes dans les laboratoires de recherche forment un formidable potentiel de calcul et de ressources mémoire accessibles à un coût très faible. Dans le cas des machines à mémoire partagée, le temps nécessaire à la construction d un graphe d accessibilité pour un modèle, peut être énormément diminué en exploitant l accès commun de plusieurs Cpu à de larges quantités de mémoire. Dans le cas des réseaux de stations de travail ou de Pc, un algorithme parallèle, pour machine mono ou multiprocesseurs à mémoire distribuée, peut permettre d utiliser efficacement toutes ces mémoires physiquement distribuées de telle sorte que des espaces d états aussi larges que l ensemble des mémoires réunies le permet, puissent être analysés sans avoir besoin de matériel spécifique ou de supercalculateurs trop coûteux.

24 24 Chapitre 2. La génération distribuée d espace d états 2.3 Approches et composants Parmi les nombreux travaux, qui ont été publiés sur la génération parallèle de graphes d états, ceux de Caselli et al. [CCBF94, CCM95] et celui de Ciardo [NC97] font office de références, et donnent les fondements de l approche et les briques de base de la discussion et des comparaisons qui vont suivre. Cette étude serait néanmoins incomplète si nous ne citions pas l un des tous premiers articles sur des algorithmes parallèles de parcours de graphe qui a été présenté par Reghbati et Corneil [RC78]. Leurs travaux incluaient l étude de parallélisme borné et non-borné dans des problèmes théoriques de graphes. Dans le parallélisme non-borné un nombre arbitrairement grand de processeurs était disponible, alors que dans le parallélisme borné, un nombre fixé de processeurs était accessible. D après les calculs, effectués par ces auteurs, basés sur les propriétés de connection des composants d un graphe, il en résultait que l algorithme de recherche en largeur d abord est le plus efficace. Quelques années après, Aggarwal et al. [AAC87] ont poursuivi et confirmé ces mêmes travaux concernant la question de la parallélisation d un parcours de graphe, sans toutefois présenter de prototype non plus. Ghosh et Bhattacharjee [GB84] ont pour leur part proposé des algorithmes parallèles de parcours en largeur d abord pour des arbres et des graphes sur des machines Simd (Single Instruction Multiple Data) à mémoire partagée, mais n adressaient pas le problème de la vérification de modèles. L article de Caselli et al [CCBF94], s inscrit directement dans la continuité de ce dernier article et constitue la base de l étude qui va suivre. Cette étude est approfondie dans notre matrice de comparaison des articles selon plusieurs critères, présentée en Annexe A Les mécanismes de distribution de la génération Les différentes approches présentées dans les articles [ADK97, CCBF94, CGN98, HBB99, HGGS00, KH99, LS99, SD97] partagent la même idée : chaque machine dans le réseau ou chaque processeur-nœud explore un sous-ensemble de l espace d états. Le graphe de tous les états accessibles est ainsi partitionné sur les différents processeurs ou nœuds de la machine parallèle donnant, par la même occasion, la possibilité au graphe d être plus large que la capacité d un seul nœud puisse permettre, et d établir l énumération des états explicitement et en parallèle. Cependant les approches diffèrent sur un bon nombre de principes au niveau conceptuel et sur des choix d implantation tels que : le choix entre une architecture à mémoire partagée ou une à mémoire distribuée, l utilisation d une table de hachage ou d un B-arbre pour stocker les états sur chaque machine, le partitionnement de l espace d états par une fonction de hachage statique ou une dynamique, permettant par la même occasion de rééquilibrer dynamiquement la charge au cours du processus, etc Les composants de la génération distribuée Tous les choix d implantation, cités précédemment, constituent autant de composants de la méthode de génération distribuée d espace d états, qu il faut considérer et justifier

25 2.3. Approches et composants 25 séparément. Nous comparons toutes les approches existantes, extraites de la littérature, entre elles pour chacun de ces composants, pour d une part, identifier leurs avantages et inconvénients respectifs, et pour, d autre part, en faire la synthèse afin de dégager les principes applicables dans le contexte de l outil Distributor. Architecture parallèle support Le premier objectif des travaux concernant la distribution de la génération d espace d états est d obtenir une vision des approches parallèles à travers différents modèles de programmation parallèle : le parallélisme de données ou Simd, pour Single Instruction Multiple Data, et le parallélisme d instructions ou Mimd, pour Multiple Instruction Multiple Data. La génération parallèle d espaces d états peut être considérée comme un système distribué dans lequel on fait des calculs parallèles. En effet, dans les systèmes distribués, même si le réseau de communication a un débit élevé, la latence liée aux distances est telle que les synchronisations sont forcément assurées par logiciel, et que seul un traitement de processus concurrents, avec un couplage relativement lâche, est possible. Ainsi, la génération distribuée n est pas adaptée à tous les types d architecture matérielle. On peut dénombrer essentiellement deux types d architecture massivement parallèle : les machines à mémoire partagée et les machines à mémoire distribuée, appelées également systèmes à passage de messages, lorsque les machines sont à mémoires physiquement distribuées. Parmi les architectures à mémoire partagée, on trouve les toutes premières machines massivement parallèles, telles que les machines Cm-2 ou Maspar, où la mémoire était physiquement partagée entre les différents nœuds de l architecture, alors que les architectures plus récentes, comme le T3-D ou le Ksr, sont à mémoire logiquement partagée. De même, parmi les machines à mémoire distribuée, on trouve des machines à mémoire logiquement distribuée, comme le Cm-5 de Tmc, le Paragon d Intel, ou encore le Sp1 d Ibm. Les machines à mémoire physiquement distribuée sont toutes celles correspondant à un ensemble de stations de travail ou de Pc reliées entre elle par un réseau d interconnection, architecture appelée plus communément grappe. Architecture à mémoire partagée Historiquement, le parallélisme de donnée fût le premier à apparaître notamment par l intermédiaire d architectures parallèles à mémoire partagée telles que les Connection Machines Cm-2, qui évoluèrent quelques années plus tard, en Cm-5. Allmaier et al. [ADK97] justifient le choix d architectures à mémoire partagée par le fait qu elles deviennent de plus en plus accessibles au travers des supercalculateurs présents dans les grandes architectures (mainframes) ou par les puissants serveurs de stations de travail. Un autre argument est qu elles offrent un modèle de programmation adapté à la mise en œuvre de larges ensembles concurrents de données non structurées. De plus, avec un tel modèle de programmation, les problèmes de partitionnement de tâches, et par suite de rééquilibrage de charge, sont infimes voir absents puisque chaque processeur-nœud a une connaissance exacte du travail restant à faire par le biais de la mémoire partagée, et ne devient inactif que lorsqu il n y a plus de tâche de prête.

26 26 Chapitre 2. La génération distribuée d espace d états Cependant, on peut retenir deux inconvénients majeurs du modèle de programmation par parallélisme de données sur machines à mémoire partagée. Bien que les espaces d états générés avec de telles machines soient très larges, d un ordre de grandeur plus grand que ceux réalisés séquentiellement, ils restent inadaptés à un tel modèle de programmation. En effet, due au manque de régularité du graphe d états, sa construction ne peut pas s adapter réellement au modèle de programmation par parallélisme de données. Cette technique ne peut donc aboutir qu à des améliorations de performances très limitées. L autre point négatif de la méthode est qu elle est peu portable et flexible. Cet aspect est directement lié à la machine elle-même en tant que support. Pour pouvoir utiliser de telles machines, comme Cm-2 ou Maspar, il faut utiliser un langage de programmation parallèle adapté, comme Cm-Fortran ou Mpl. Ce modèle de programmation est donc hautement dépendant du langage d implantation et doit respecter des caractéristiques spécifiques à la machine. De plus, les progrès technologiques, s appuyant notamment sur la progression exponentielle des performances des circuits intégrés en terme de vitesse et de fonctionnalités, ont permis une croissance continue des performances des machines séquentielles, qui sont devenues aussi puissantes, voire plus puissantes que certains supercalculateurs pour des coûts beaucoup plus faibles. Les langages de programmation et les compilateurs associés sur les machines séquentielles standards ont également beaucoup évolué et permettent une programmation parallèle efficace pour des performances aussi élevées que sur des architectures à mémoire partagée dédiées au calcul parallèle. Les travaux de Caselli et al [CCM95] sur les architectures Cm-5 et Cray T3D marquent un tournant dans la méthodologie de programmation de la génération parallèle d espaces d états sur supercalculateurs. On passe du parallélisme de données à celui d instructions, mais également de systèmes à mémoire partagée aux systèmes à mémoire distribuée, même si dans le cas du Cm-5 et du Cray T3D, les deux systèmes soient encore possibles. Allmaier et son groupe [ADK97] sont parmi les seuls à ce jour à poursuivre leurs travaux sur des machines à mémoire partagée, mais cette fois sur des machines Mimd, telles que les Spp1600 et les Sun Enterprise Server 4000, bien que ce genre de machine parallèle soit loin d être accessible et répandue dans le monde. L inconvénient majeur d une telle approche est alors le passage à l échelle de la méthode, car le nombre de processeurs et l espace mémoire disponible sur de telles architectures sont limités par les lois physiques de la nature; et ces limites ont, pour la plupart d entre elles, déjà été atteintes, pour différents composants des machines à mémoire partagée. Architecture à mémoire distribuée Récemment [HGGS00], de nouvelles méthodes prometteuses faisant usage des architectures distribuées ont été introduites, notamment concernant la capacité mémoire. Ces méthodes utilisent le réservoir collectif des modules de mémoire dans un réseau de processus. Des problèmes de taille non gérable séquentiellement peuvent désormais être résolus en combinant la mémoire principale de grappes de machines. Un résultat des articles de Caselli [CCBF94, CCM95] est que l utilisation de systèmes informatiques Mimd à mémoire distribuée est plus profitable que l utilisation de machines Simd telles que les Cm-2.

27 2.3. Approches et composants 27 Parmi les machines Mimd à passage de messages, la tendance actuelle se porte vers des processeurs standards bon marché sur réseau standard. Ces grappes de machines, comme elles sont couramment appelées, sont des stations de travail, ou n importe quelles machines mono ou multi-processeurs, interconnectées par des réseaux locaux à très hautes performances. Cette notion de grappe de machines est très présente dans les développements récents de techniques de génération distribuée d espace d états, car il est d une part très facile de construire sa propre grappe expérimentale ou d utiliser un réseau local existant de machines. Et d autre part, cette machine parallèle n a pas besoin d être spécifique à un type de problème, elle peut aussi bien servir comme une machine séquentielle, un service de fichiers distribués, ou pour tout type de calcul scientifique hautement parallèle. C est une façon efficace et peu coûteuse de mettre à profit la mémoire principale de stations de travail en réseau ou de Pc mis en grappe, présents et maintenus dans les parcs de machines des laboratoires de recherche ou des entreprises de nos jours. Cette architecture massivement parallèle répond parfaitement aux besoins de ressources en calculs et en mémoire que les machines séquentielles ne peuvent pas fournir pour vérifier des applications à très large espace d états. Contrairement aux machines à mémoire partagée, ce genre de machines à mémoire distribuée souffre du problème clef de l implantation d une stratégie efficace de partitionnement, s adaptant dynamiquement, pour distribuer l espace d états sur différents processeurs, et de l association du partitionnement avec des mécanismes de rééquilibrage de charge. L évolution technologique conduit ainsi à l utilisation, pour la génération d espace d états sur machines massivement parallèles, de l approche Mimd avec des mémoires physiquement distribuées pour pouvoir utiliser un grand nombre de processeurs et d importantes quantités de mémoire de coût raisonnable (RAM dynamique). L alternative est alors entre des machines ayant plusieurs espaces d adressage, un par mémoire associé à chaque processeur, telles que les grappes, et des machines avec un seul espace d adressage, c est à dire des mémoires logiquement partagées, aussi bien celles virtuellement partagées (Ksr) que celles avec accès non uniforme sans copies multiples (T3D). Partitionnement des tâches Alors que pour les architectures à mémoire partagée, les mécanismes de synchronisation [AKH97] disponibles suffisent à la génération distribuée d une partie du graphe d états par chaque processeur, dans le cas des architectures à mémoire distribuée, on doit définir une fonction de partitionnement des états. En effet, chaque Cpu n a accès qu à la partie limitée de l espace d états, localisée dans sa mémoire privée, qui lui est affectée par la fonction de partitionnement. Le principal problème de la génération distribuée sur systèmes multi-processeurs est le besoin d avoir une bonne fonction de partition des états du graphe généré sur chaque processeur. Dans le meilleur des cas, cette fonction devrait fournir un bon équilibre à la fois en utilisation mémoire et en coût d exécution, et devrait également être automatique pour libérer

28 28 Chapitre 2. La génération distribuée d espace d états l utilisateur d une connaissance approfondie du mécanisme de partitionnement. Il existe un bon nombre de ces fonctions dans la littérature [Cia01, HBB99, HGGS00, KMHK98]. Une fonction de partition se caractérise par les points suivants : Elle doit partager a priori l espace d états de manière distincte entre tous les processeurs afin que chaque état global n ait qu un processeur responsable de son traitement. La fonction doit également distribuer de manière égale les états parmi les Cpu. L équilibre des charges, qui en résulte, est un facteur de performance important puisqu il traduit une utilisation équitable de chacune des mémoires locales à un processeur. Un déséquilibre de charge entraînerait une mauvaise gestion de la mémoire et le risque d arrêter prématurément la génération distribuée dans le cas où la mémoire d un processeur se soit remplie d états alors que celles d autres processeurs seraient inutilisées. On peut aussi vérifier qu une fonction de partitionnement est bonne en évaluant le pourcentage d arcs, entre états du graphe, appartenant à des processeurs différents, et donc coupés par le partitionnement. Pour des raisons d efficacité, cette fonction doit favoriser le partitionnement sur chaque processeur de régions du graphe entièrement connectées, ou principe de localité, afin de réduire la quantité de communication nécessaire à la génération distribuée et qui engendre le surcoût le plus important de la méthode dans le cadre des architectures à passage de messages. De nombreuses solutions de partitionnement ont été proposées dans les travaux sur la génération distribuée d espaces d états : la fonction de hachage statique [CGN98], le rééquilibrage automatique ou dynamique de charge, parfois appelée technique de repartitionnement [NC97]. Fonction de hachage statique [CGN98] Les fonctions de hachage sont utilisées pour partitionner les états sur les processeurs. Elles sont simples à implémenter et présentent de bons résultats en coût de calcul et de mémoire. La fonction de hachage fournie par l utilisateur a l avantage, si elle est bien définie, d équilibrer la partition de charge de travail par processeur, et d obtenir également de bons temps d exécution. Cependant, pour définir une telle fonction, l utilisateur a besoin d une très bonne compréhension du développement futur de l espace d états. De plus, n ayant aucune garantie que les mémoires de tous les processeurs soient utilisées au mieux, le nombre de nœuds du graphe d accessibilité découverts par processeur peut différer à cause d une fonction de hachage imparfaite, ce qui traduit une utilisation non-optimale de l espace mémoire. Le but de la fonction de partitionnement est d équilibrer au mieux la charge entre toutes les machines. Un autre inconvénient, lié cette fois aux données manipulées lors de la génération distribuée, concerne la portabilité de la méthode. Selon la représentation binaire adoptée pour la description d un état, il se peut que le vecteur d état soit différent sur différentes architectures d ordinateur. La fonction de partitionnement par hachage renverra donc dans ce cas des valeurs distinctes de processeurs pour un même et unique état, faussant complètement

29 2.3. Approches et composants 29 la génération. Un autre problème de la fonction de hachage est qu elle n adresse pas le problème de la minimisation du nombre de transitions entre différentes parties de l espace d états, appelées plus communément cross arcs. Cette minimisation traduit le principe de localité que doit respecter tout partitionnement. En respectant ce principe, la génération d une partie de l espace d états sur chacun des processeurs est accélérée car essentiellement locale, et les coûts en communication inter-processeurs diminués. Rééquilibrage dynamique de charge [NC97] Une autre approche, n utilisant pas les fonctions de hachage, est l équilibrage dynamique de charge, en prenant pour charge, la consommation mémoire de chaque processeur, et permet une distribution égale des portions de l espace d états parmi les processeurs, ainsi qu un rééquilibrage dynamique. Le point faible d une telle méthode est le surcoût engendré en calcul et en communication. Son point fort est que, justement, le calcul de génération ne sera pas arrêté à cause d un manque de mémoire sur un sous-ensemble de machines alors que les mémoires locales à d autres Cpu seraient largement inutilisées. Une méthode de synchronisation, appelée séparation anticipée ou splitting in advance, a été développée pour permettre à un B-arbre de se rééquilibrer automatiquement [AKH97]. Dans [ADK97] une fonction de partitionnement est gérée par un processus maître. Il ordonne les marques d un réseau de Petri stochastique (Spn) et donne aux esclaves des paquets contigus de taille égale de marques à traiter. Pour les Bdd, [HGGS00] définissent une fonction booléenne de partage, ou boolean slicing function, au sein d un algorithme flexible de partitionnement, qui leur permet une grande réduction des besoins en espace et un bon équilibrage de charge. Ces deux techniques précédentes ont une structure particulière, puisqu elles font intervenir un processus superviseur qui surveille les besoins mémoire de chacun des nœuds et qui démarre dynamiquement la procédure de rééquilibrage. Enfin, Nicol et Ciardo [NC97] proposent une fonction de repartitionnement dynamique des charges de travail, adaptée aux applications parallèles exhibant des changements graduels de charge de calcul, car ayant des comportements simples. Cette fonction est utilisée selon une fréquence de partitionnement souhaitée par l utilisateur. Les critères de repartitionnement sont un équilibre entre la charge des tâches locales ajoutée à celle de l émission par le processeur, et la charge de réception par ce processeur. Structures de données requises L espace d états peut être très irrégulier, un état pouvant très bien n avoir qu un seul successeur ou des millions de successeurs. Cet espace grandit dynamiquement, et aucun outil ne permet à ce jour de connaître sa taille et sa forme à l avance. Pour ne pas être pénalisé par cette irrégularité, les structures de données employées lors de la génération doivent être le plus possible adaptées aux caractéristiques typiques de l espace d états. Nous avons vu dans l algorithme séquentiel 2.1 que la génération d espace d états nécessitait trois grandes structures de données ayant des rôles totalement différents dans la génération. Pour chacune des trois entités énoncées précédemment à savoir, l ensemble des états explorés E, des états visités V, et des transitions T, le choix entre les différentes structures de données est décidé

30 30 Chapitre 2. La génération distribuée d espace d états par l ensemble des opérations effectuées sur ces entités : 1. V := V \ {s} (extraction d un état dans un ensemble) 2. s E V (recherche d un état dans un ensemble) 3. V := V {s }; E := E {s } (insertion d un état dans un ensemble) 4. T := T (s,a,s) (insertion d une transition dans un ensemble) Structures pour les états nouveaux La première opération requiert d être capable d enlever un état facilement de la structure de donnée représentant V, aussi bien que d ajouter un état à la même structure (troisième opération). Les files et les piles semblent être les mieux appropriées. Bien que le coût mémoire de ces deux structures de données soit similaire, l ordonnancement résultant des états diffère légèrement et peut avoir une influence sur la convergence de la procédure itérative lors de la génération de l espace d états. Le problème de ces structures survient lorsqu il est question de la deuxième opération effectuée sur cette structure. La recherche d un élément n est pas du tout adaptée à de telles structures, c est pourquoi les outils développés dans la littérature [HBB99, KMHK98, ADK97] ne se basent pas sur un algorithme séquentiel identique à celui illustré en Fig.2.1. Leur ensemble d états E contient tous les états du graphe d accessibilité découverts jusque là, y compris les états pour lesquels on n a pas généré les successeurs. Leur ensemble d états V contient les états en attente d être utilisés pour générer les transitions et les états successeurs à cet état. Il y a donc une redondance dans leurs structures manipulées puisque des états peuvent se retrouver dans les deux ensembles en même temps, et par suite perte de mémoire, car leurs ensembles ne sont pas disjoints. Cette mécanique leur est nécessaire pour pouvoir effectuer des recherches et insertions performantes de nouveaux états dans des structures de donnée adaptées, décrites dans le paragraphe suivant. Structures pour les états explorés La deuxième opération est essentielle pour une efficacité générale de la mémoire : le stockage interne de E. Pour assurer qu un état global n a pas été inséré plusieurs fois dans le graphe, l ensemble des états déjà rencontrés, doit être parcouru dès qu un état est nouvellement découvert. Pour être capable de générer des espaces d états larges en un temps acceptable, il est crucial de maintenir des structures de données de recherche qui permettent des recherches et des mises à jour très rapides. Les grands critères traduisant son efficacité sont essentiellement un temps de recherche court et une consommation mémoire basse. Parmi les techniques existantes, deux solutions ont été retenues : les arbres de recherche équilibrés et les tables de hachage. Le principal avantage des arbres de recherche équilibrés est que le processus de recherche d un élément est, en théorie, de l ordre de O(log n), n étant le nombre total d états, ordre qui correspond à la profondeur maximale de l arbre. Bien que les tables de hachage aient une recherche de l ordre de O(n), à cause des listes chaînées qui peuvent être de longueur maximale n, on observe en pratique des temps de recherche

31 2.3. Approches et composants 31 bien plus rapides avec les tables de hachage qu avec les arbres de recherche équilibrés pour un même ensemble d états. Seulement, lorsque l on utilise les arbres équilibrés, de nombreuses formes de surcoût apparaissent : le besoin d au moins deux pointeurs pour les fils gauche et droit, mais aussi d un pointeur pour le nœud du père nécessaire dans les phases de rééquilibrage, et également un pointeur pour accéder aux informations de l état en question. Tous ces pointeurs forment un surcoût significatif en place mémoire. le fait que les états nouveaux n apparaissent pas immédiatement dans l arbre. La recherche de l existence des états nouveaux dans l arbre est alors toujours sans succès et coûte à chaque fois O(log n) étapes, ce qui contribue à un surcoût en calcul assez important. Sur les machines à mémoire partagée, le problème clef pour la parallélisation est l implantation d une structure de données partagée qui permette des accès concurrents efficaces pour accéder aux nœuds du graphe. Une structure type est le B-arbre avec des mécanismes spéciaux de verrous et de synchronisation. En revanche, les structures de données basées sur du hachage ne devraient pas souffrir des inconvénients ci-dessus. La recherche d états nouveaux est immédiate par hachage sur l état, dans l hypothèse où la fonction de hachage ne présente pas de collisions. Et le seul pointeur utilisé est celui pour accéder le contenu d un état. Cette méthode présente donc un gain mémoire et calcul non-négligeable. Comme aucun élément n est enlevé de E, une forme très simple de hachage sans chaînage peut être utilisé. La présence d un état peut être vérifiée directement à partir de l adresse calculée du nouvel état. Une solution aux collisions qui sont susceptibles de se produire, est l utilisation de la méthode dite d adressage ouvert avec double hachage. Pour répondre au problème de la décision a priori de la taille de la table de hachage, une solution est d allouer la taille maximale en mémoire. Bien que pouvant être trop large et utiliser des ressources inutiles, elle présente l avantage de réduire les collisions. Les principaux avantages d une table de hachage sont une implémentation facile, des mécanismes de synchronisation d accès très simples dans le cas des machines à mémoire partagée, et enfin un gain mémoire important par rapport aux arbres de recherche, puisqu aucun pointeur gauche ou droit pour les fils d un nœud du graphe n a besoin d être stocké en mémoire. Les principaux inconvénients sont les définitions de la taille de la table et de la fonction de hachage elle-même. Si les transitions doivent être stockées en mémoire, on ne peut pas allouer la taille maximale en mémoire pour la table d états car on doit également stocker localement à la machine les transitions entre les états du graphe, ou arcs, dont on ne connaît pas a priori le nombre. On devrait donc implanter une fonction de hachage dynamique ce qui détruit le premier avantage cité auparavant. D autre part, afin de gérer les collisions possibles dans la table de hachage, il est nécessaire d avoir une liste chaînée d états pour chacune des entrées de la table. Ces listes chaînées prennent de la place en mémoire et donc enlèvent le deuxième avantage de cette méthode.

32 32 Chapitre 2. La génération distribuée d espace d états Structures pour les transitions L attitude d allouer la taille maximale en mémoire pour stocker l ensemble des états dans une table de hachage par exemple, n est possible que lorsque l ensemble des transitions atteint une largeur telle que l on ne peut pas le garder en mémoire, laissant ainsi la mémoire pour le seul stockage des états. Les transitions peuvent alors être simplement écrits sur un outil de stockage secondaire, comme un disque dur. Cependant, plusieurs tendances pour le stockage des transitions sont observables dans la littérature. Dans le cas des Spn et des chaînes de Markov à temps continu (Ctmc), ces transitions font partie intégrante de la matrice générée lors de la construction du graphe [NC97]. Dans le cas du stockage des états par un B-arbre, les transitions sont modélisées par les arcs entre les nœuds, et sont donc, comme dans le point précédent, stockées en mémoire soit par l intermédiaire de pointeurs, soit sous forme de tableau de transitions. Le rôle des transitions est également double. En plus de représenter le passage d un état à un autre par l exécution d une action particulière, elles contiennent souvent des informations utiles lors de la phase de vérification. Par exemple, elles peuvent contenir des taux de probabilité, avec lesquels les changements d états interviennent, dans le cas des chaînes de Markov. Elles contiennent souvent les informations relatives à l action identifiant cette transition. Puisque l essentiel de l information d un graphe d états peut être donné par les actions, le contenu des états devient irrelevant dans les transitions. Une technique consiste à les remplacer par des nombres entiers les identifiant. La difficulté est d avoir des numéros uniques pour chacun des états générés, que seul le processus responsable d un état peut donner. C est pourquoi deux techniques principales pour le stockage des transitions sont utilisées dans la littérature : le format de stockage par ligne, row-wise, et celui par colonne, ou column-wise. Elles ont été principalement introduites par Ciardo dans [CGN98] dans le contexte de construction de la matrice représentative de chaînes de Markov, d où les termes ligne et colonne. Le format column-wise correspond au stockage des arcs arrivants sur les états par le processeur responsable de ces états. Ainsi, lors de la découverte d un nouvel état ne lui appartenant pas, un processeur va envoyer cet état et la transition qui y mène au processeur qui a la charge du nouvel état. Dans la transition envoyée, l identification de l état de départ est présente et permet le stockage de l information complète localement au processeur récepteur du message. Le format row-wise est l inverse de cette méthode puisqu il consiste à stocker les nouvelles transitions par le processeur qui les a générées. Le problème de cette méthode, est le besoin d attendre le numéro identifiant l état trouvé, par le processeur qui en a la responsabilité, et la possibilité de que deux processeurs se retrouvent interbloqués sur l attente d un accusé de réception de l autre. Le choix entre ces deux techniques est un compromis basé sur le coût en communication qu elles représentent, notamment entre le nombre de messages échangés, plus important dans la méthode row-wise, et la taille des messages envoyés, plus larges dans la méthode column-wise. Structures pour les états Parmi les autres structures de données manipulées, celles de la représentation de l état est également très importante. La fonction succ(s) ne peut être exécutée efficacement que lorsque l état global du système peut être lu directement depuis la description de l état. Elle doit vérifier si les transitions sont permises et dans quel état,

33 2.3. Approches et composants 33 l exécution de la transition conduira le système. Pour ces objectifs, des techniques efficaces basées sur l encodage d état, tel que le bit state hashing [Hol91], sont connues. Pour réduire les exigences en mémoire pour stocker les états, on peut utiliser des techniques probabilistes basées sur les fonctions de hachage. Cette technique est similaire à celle du bit state hashing, seulement elle ne repose pas sur une allocation statique de la mémoire, mais à une allocation dynamique. Le principal inconvénient d une telle méthode est qu il y a un risque, aussi infime soit-il, d omettre des états, ce qui ne correspond pas au concept de la vérification énumérative d un système. Une autre technique est celle de la compression des états. Cette technique de compression peut réaliser une partition des vecteurs d état pour améliorer le taux de compression. La partition est réalisée au niveau de la table de hachage habituellement utilisée pour accélérée les recherches dans l espace d états. Elle apporte ainsi un gain en mémoire non négligeable lors de la génération de l espace des états. Type de communication Le large surcoût en communication, dû à un mauvais partitionnement, que doit subir la génération distribuée d espace d états a un impact énorme sur les performances de systèmes à mémoire partagée comme les réseaux de machines connectées entre elles par un réseau local (Lan) de faible capacité en bande passante, de type Ethernet. En revanche, il n affecte en rien les performances pour les architectures à mémoire partagée, de type SP2, où les processeurs sont reliés par un commutateur croisé, car la localité des données partitionnées est, dans ce cas précis, physique. Pour palier au problème du surcoût engendré par les communications, et notamment des millions d états et de transitions qui devront transiter sur le réseau, dans le cas des machines à mémoire distribuée, plusieurs approches complémentaires sont possibles. Le recouvrement des communications par du calcul est la solution la plus appropriée. Son efficacité est optimale lorsque le processus de génération lancé sur chaque machine est multi-threadé; un thread s occupant des calculs et l autre des communications, les deux se synchronisant sur les accès aux différentes structures de données partagées, notamment l ensemble des états nouvellement découverts. Dans le cas de processus séquentiel, ce recouvrement est possible mais limité car le comportement du processus est fixé à l avance et ne s adapte pas, en résultat, forcément à toutes les situations critiques de communication. Une autre technique consiste à regrouper des messages dans un tampon logique, ou buffer, avant de les envoyer sur le réseau. Une fois un seuil de remplissage atteint dans le buffer, le processus envoie la totalité du groupe de messages économisant ainsi de nombreux accès réseau, accès qu il aurait du établir pour chacun des messages du groupe. La taille du tampon est alors un choix critique de conception. Un tampon de petite taille entraîne des échanges fréquents de petits paquets entre les processeurs, et l efficacité de la communication risque d être pénalisée par une latence élevée. A l opposé, un tampon large augmente beaucoup la taille des paquets échangés, et affecte la performance de la communication si la bande passante accessible est insuffisante. Des tests en fonction de la taille des tampons ont démontré

34 34 Chapitre 2. La génération distribuée d espace d états l importance de buffer de taille large, le but étant d exploiter au mieux le débit du réseau d interconnection [MCC97]. Enfin reste le choix d un modèle de programmation parallèle de la communication adapté au type de problème qu est la génération distribuée d espace d états. Les processus communiquants peuvent reposer sur différents mécanismes de communication. Le système des sockets, en premier lieu, représentent le support de communication le plus diffusé dans le monde permettant à l outil une bonne portabilité [LS99]. Seulement cette méthode est coûteuse en développement et représente une maintenance difficile. En 1990 est apparue la technique Pvm, pour Parallel Virtual Machine. Son but était d offrir un modèle simple de programmation parallèle par passage de messages. Elle fût rapidement suivie par un standard en 1995 : Mpi pour Message Passing Interface. L intérêt d une telle technique est qu elle est efficace et proche de la machine. Elle dispose d une grande portabilité sur des machines hétérogènes, ayant ou pas des processeurs identiques. Elle est d ailleurs largement utilisée dans les articles [CGN98, SD97, KH99] sur la génération distribuée d espaces d états. L inconvénient majeur d une telle méthode est qu elle entraîne une programmation complexe, due notamment à l enchaînement de primitives de communication send/receive. De manière plus générale, le modèle de programmation par passage de messages est adapté pour des schémas de programmation simples de type maître/esclave de base, ou de programmes Spmd. Il devient beaucoup plus difficile à mettre en œuvre pour des schémas impliquant une algorithmique distribuée complexe, à cause des nombreux interblocages et du non-déterminisme des opérations qu il faut éviter. La génération distribuée d espace d états repose à la fois sur un schéma de programmation similaire du type maître/esclave de base, tout en utilisant de l algorithmique distribuée, notamment pour la détection distribuée de la terminaison des processus. Le modèle par passage de messages est donc relativement bien adapté dans le cadre de machines à mémoire distribuée. Format de description du modèle à vérifier Des nombreux travaux sur la génération distribuée d espaces d états, on peut extraire deux approches concernant le rôle du format de description du modèle pour l analyse d accessibilité : d un côté, les algorithmes sont dédiés à un formalisme spécifique, de l autre, ils sont totalement indépendants. Parmi les formalismes spécifiques, on retrouve ceux de bas niveau, comme les réseaux de Pétri ou encore les chaînes de Markov, ou ceux de plus haut niveau, comme Murphi, Promela, etc. L inconvénient d une telle approche est que tous les systèmes ne peuvent pas être décrits efficacement dans ces formalismes, ce qui réduit énormément le champ d action des outils correspondants. Cependant, lorsque la description est adaptée [SD97, LS99], les performances obtenues sont, la plupart du temps, très satisfaisantes et généralement meilleures que les outils indépendants des formalismes d entrée [Cia01]. Le potentiel de la parallélisation est exploité si la méthode est spécifique à un problème, comme dans [MCC97] dans le cas des Gspn. Le formalisme choisi est en rapport avec le type d architecture du système que l on cherche à modéliser. Pour les modèles à événements

35 2.3. Approches et composants 35 discrets on préférera un langage de haut niveau tel que LOTOS, alors que pour les modèles à flots continus, les réseaux de Pétri stochastiques sont très bien adaptés. Terminaison distribuée La génération distribuée de l espace d états repose en partie sur des techniques issues du domaine des systèmes distribués, comme par exemple la terminaison distribuée [MC98]. Pour situer le problème principal que doit faire face la détection distribuée de la terminaison, dans le cadre de la génération répartie de l espace d états, nous introduisons la notion de messages dits, venants du futur. Ces messages correspondent aux messages pouvant arriver sur un site après que celui-ci ait émis les informations concernant son status, actif ou inactif aux autres processus selon un protocole défini à l avance. De nombreuses techniques existent pour contrer le problème des messages venant du futur. Une technique connue, consiste à effectuer deux vagues successives de test de la terminaison afin de voir l évolution des canaux de communication et des piles d états locales aux processeurs. Cette méthode permet d atteindre un point fixe de l état du système sur l ensemble des messages émis et celui des messages reçus si la génération est réellement terminée. Ce point fixe n est autre que la terminaison elle-même. De nombreux algorithmes existent, et parmi les plus connus ceux de Dijkstra [DFG83] et de Misra [Mis83]. La terminaison y est basée sur la circulation d un jeton sur un anneau virtuel FIFO. La méthode de Dijkstra s appelle d ailleurs Circulating Probe Algorithm. Chaque site, ou machine, se voit attribuer une couleur blanche ou noire, initialement blanche. La couleur noire signifie que le site a été actif depuis le dernier passage du jeton, et la couleur blanche exactement l inverse. Le jeton porte un compteur des sites trouvés passifs. La terminaison est détectée lorsque tous les sites sont blancs après un tour. Cette technique n est pas la seule à être utilisée dans la littérature. Certains auteurs n hésitent pas à créer leurs propres algorithmes adaptés à leur système [CGN98]. Cependant, étant trop spécifique, l outil de génération en est pénalisé, sa portabilité également. Dans le même esprit que la technique de Dijkstra, Mattern [Mat87] a développé une méthode pour détecter la terminaison d un groupe de processus distribués. Bien que cette technique n a pas été utilisée pour la génération parallèle des espaces d états, elle est très intéressante car facile d implémentation et disposant de bonnes propriétés. L une d elles est la possibilité de déclenchement de l algorithme de terminaison tard dans le processus d analyse, contrairement à la méthode de Dijkstra, où les sites doivent changer de couleur à tout instant dès que la génération a commencé. L algorithme de Mattern repose sur un jeton et un anneau virtuel FIFO également. Seulement, la terminaison ne peut être détectée qu après deux tours, et deux tours exactement, sauf si elle échoue. L information véhiculée par le jeton lors du premier tour est la somme du nombre de messages reçus localement à chacun des sites. Après un tour, il contient donc le nombre total de messages reçus par l ensemble des sites. Le second tour consiste à faire de même mais pour le nombre de messages émis par chacun des sites. Ainsi, après le second tour, on compare le nombre de messages reçus au premier tour avec le nombre de messages émis au second. S ils sont égaux, la terminaison

36 36 Chapitre 2. La génération distribuée d espace d états est détectée. Type de vérification Une fois l espace d états partitionné entre toutes les machines, il est nécessaire d avoir des mécanismes permettant de récolter les informations éparpillées pour pouvoir établir une vérification du système. Techniques La parallélisation des outils de vérification est en plein essor [Ing00], celle concernant la génération de l espace d états est partagée entre deux techniques : l analyse parallèle symbolique d accessibilité et l analyse parallèle énumérative d accessibilité. Nous avons vu (cf chapitre 1) que la vérification symbolique constituait également une approche pour combattre l explosion combinatoire de l espace d états. Plusieurs travaux actuels [Ing00] tentent de paralléliser cette approche. Un algorithme d analyse parallèle d accessibilité basé sur les Bdd (Binary Decision Diagrams) est présenté dans Heyman et al. [HGGS00]. Une représentation Bdd compacte y est définie et permet la coordination entre toutes les machines par l envoi de Bdd complets d un processus à l autre, à la place des buffers de transitions habituellement échangés. Cette approche ne gère pas les états individuellement, mais des ensembles d états représentés sous forme de Bdd. Les résultats énoncés sont surprenants en nombre d états générés, mais ne donnent pas un modèle final explicite et facile d utilisation pour la vérification. La vérification exhaustive exacte permet, quant à elle, d obtenir une description précise de l espace d états une fois construit et obtenu, et donne alors le support le plus pratique et performant pour la vérification de propriétés, telles que celles exprimées en logique temporelle. Fusion des graphes distribués Après avoir généré de manière distribuée l espace d états, la seconde phase nécessaire pour la vérification, est la fusion des graphes distribués. Aucun article ne précise comment se déroule une telle phase, mis à part ceux travaillant sur les chaînes de Markov. L espace d états est alors la matrice éparpillée représentative de la chaîne Markov [NC97]. La vérification consiste à effectuer des opérations de multiplications en parallèle pour résoudre les systèmes d équations de la propriété cherchée, la plus connue étant la solution par état constant ou steady-state solution. Les articles étudiés étant plus impliqués dans la partie génération de l espace d états que dans la partie vérification, aucune technique de fusion de graphes n y est présentée. Cette phase de vérification est absente de la plupart des articles traitant la génération distribuée d espace d états, mais fait partie de la majorité des travaux futurs énoncés en perspectives de chacun de ces auteurs.

37 2.4. L évolution des méthodes : synthèse et discussion 37 Performances de la technique Les deux grands critères de performance d un outil de génération parallèle d espace d états sont : l accélération du temps de calcul, ou speedup, par rapport aux outils séquentiels d une part, et par rapport aux outils parallèles existants d autre part, et l extension de la cardinalité de l espace résolvable en comparaison avec les espaces d états résolus jusqu alors. Les mesures s effectuent donc au niveau des Cpu et de l usage mémoire. Les travaux de génération sur machines parallèles ont permis l analyse de problèmes de complexité sans précédent, car beaucoup moins contraints par la taille de l espace d états sous-jacent correspondant. Un tel exemple de protocole de cohérence complexe est le protocole Dash [LLG + 92]. La taille maximale d espace d états générée jusqu à présent est de états et de transitions pour un modèle formalisé par un réseau de Pétri à 22 places du système Flexible Manufacturing Systems avec k, une variable du système incrémentant le nombre de configurations possibles, égale à 12 [KMHK98]. Cette expérimentation fût réalisée sur une machine Fujitsu AP3000 à 12 nœuds sous Solaris avec des processeurs 200MHz UltraSparc, 256MB de RAM et 4GB de disque local. Mis à part l outil développé par [LS99], toutes les techniques parallèles apportaient à la fois une accélération des calculs par rapport à la version séquentielle de la génération d espace d états, et une augmentation de la cardinalité du nombre d états. Toutes les accélérations réalisées sont globalement linéaires à environ 80% du nombre de machines utilisées. Par exemple, en gardant les travaux cités précédemment [KMHK98], ces auteurs obtiennent une accélération de 9,12 sur une machine à 12 nœuds, ce qui représente une efficacité de 76%. Parmi les limitations sévères soulignées par les différents articles, celle qui revient le plus souvent est celle de la mémoire [Cia01]. La principale source de conflit dans la génération explicite d espace d états est la mémoire, car c est elle qui limite la taille d un graphe d accessibilité décrit explicitement. Les limitations qui viennent ensuite, sont les surcoûts liés à la communication et à la gestion des buffers de communication [KMHK98, ADK97, SD97], à cause d un pourcentage trop élevé de transitions entre états n appartenant pas au même processeur. Ces transitions, ou cross-arcs, sont le résultat d une mauvaise fonction de partitionnement [HBB99, LS99]. Enfin, les calculs d opérations spécifiques, telle que la multiplication parallèle des vecteurs d une matrice, peuvent s avérer également très coûteux en temps d exécution [KH99]. 2.4 L évolution des méthodes : synthèse et discussion Chacun des articles de la littérature portant sur la génération distribuée d espace d états a apporté un développement notable d un des composants cités auparavant. Caselli, Conte, Bonardi et Fontanesi ont été les précurseurs de la parallélisation de la vérification. Dans [CCBF94] ils présentent une méthode ad hoc pour partitionner les états en utilisant une fonction de hachage avec pour clef de recherche l état ou marque du réseau

38 38 Chapitre 2. La génération distribuée d espace d états de Pétri analysé. La recherche d un nouvel état se fait en parallèle, l implémentation de leur prototype est testée complètement sur une machine à mémoire partagée Cm-2, et ils arrivent à générer le plus grand espace d états alors connu (10 6 états). Il s agit des tous débuts de la génération massivement parallèle d espace d états. L utilisation d une architecture coûteuse comme la Cm-2 est mal adaptée au parallélisme du problème, et reflète des résultats catastrophiques par rapport aux solutions séquentielles. Cependant, leur réflexion intrinsèque est bonne et servira pour les futurs travaux. La suite des travaux de Caselli et al. [CCM95] repose sur une architecture de support nouvelle. Ils utilisent des machines Mimd (Cm-5 et Cray T3D) à la place des machines Simd précédentes, ce qui illustre bien le passage du mode de programmation vectoriel vers le massivement parallèle. Un autre indicatif de ce changement est le fait que Cray n avait que des machines vectorielles, et que le Cray T3D soit leur première machine massivement parallèle. Ils proposent cette fois une approche efficace et nouvelle de génération distribuée et parallèle de graphe d accessibilité, basée sur une allocation a priori des états aux nœuds de leurs machines parallèles en utilisant des techniques de hachage. Les architectures utilisées permettant à la fois le parallèlisme de données et le parallèlisme d instruction, leur article établit des comparaisons entre les avantages de chacune des méthodes en vue d une implémentation complète d une méthode de génération distribuée d espace d états pour Gspn, par la construction de Trg pour Tangible Reachability Graph, par passage de messages. Ciardo et al. ont ensuite étendu cette approche [CGN98] en enlevant un certain nombre de barrières de synchronisation, augmentant ainsi l efficacité globale du système. Ils ont rendu leur algorithme de génération distribuée indépendant du langage de spécification du modèle à analyser. Cependant, il est à noter quelques difficultés, dans leur méthode, concernant un équilibrage propre de charge. Ajouté à cela, le principal défaut de leur technique est que l utilisateur doit avoir une compréhension approfondie de comment l espace d états du système modélisé se développera pour paramétrer au mieux la fonction de hachage. Caselli et al. continuent leurs travaux [MCC97], en insistant sur des techniques de compression de l espace d états et de communication efficace. Munis d un cluster de 14 Pc, ils arrivent à générer et résoudre des Ctmc de d états. Seulement, leur solution de chaînes de Markov souffre du degré de parallélisation introduit dans la méthode Gauss-Seidel, et du taux bas entre les calculs et la communication pour chaque itération. Allmaier et al. [AKH97] ont, quant à eux, proposé récemment une approche de génération et de solution Mimd utilisant un système multiprocesseurs à mémoire partagée onéreux. Bien qu ayant des résultats prometteux, le besoin de matériel spécifique reste un inconvénient majeur. Pour eux, la mémoire est un facteur limitant. Leur groupe est l un des seuls à utiliser encore des machines parallèles à mémoire partagée. Dans leur article, ils font une très bonne présentation des grands points de la génération parallèle à mémoire partagée de l espace d états énoncée précédemment, mais complétée par la construction du Ctmc avec l analyse de ce dernier. Ils concluent par une ouverture sur les algorithmes avec mémoire distribuée. Dans une extension à un modèle de grappe, ces mêmes auteurs [AH97] utilisent des techniques, peu performantes au vu des résultats, dédiées pour l équilibrage de charge qui di-

39 2.4. L évolution des méthodes : synthèse et discussion 39 visent le travail proprement sur toute la grappe sans fonction de hachage. Les accélérations et tailles maximales d espace d états ne sont pas très importants. Ils proposent également une meilleure utilisation des larges mémoires principales de multiprocesseurs modernes. Ces travaux sont parmi les premiers concernant la génération parallèle a mémoire partagée d espace d états pour modèles stochastiques. Dans [ADK97], les mêmes auteurs mettent en valeur leur supériorité sur la méthode pour les machines à mémoire partagée, dû à un manque de littérature sur ce type d architecture, et rendent obsolètes les travaux et problèmes présentés avant eux (Ciardo et Marenzoni) en donnant une solution pour les machines à mémoire distribuée. Ils sont également parmi les premiers à mettre en place un rééquilibrage dynamique de charge. Une vision d ensemble y est dépeinte ainsi que la comparaison de deux algorithmes parallèles pour la génération de l espace d états dans la modélisation stochastique. Ils établissent une bonne introduction de la génération parallèle d espace d états, des langages sources décrivant des modèles, du processus global ainsi que des spécificités des deux méthodes. Stern et Dill [SD97] ont récemment décrit une approche, basée sur Murphi, d énumération distribuée et parallèle d espace d états très similaire à Ciardo et al. [CGN98], Caselli et al. [CCM95], et Knottenbelt et al. [KMHK98], rendant de très bonnes accélérations également, proches du linéaire. Leur algorithme est basé sur un parcours en largeur d abord, et est dédié à des ordinateurs parallèles à mémoire distribuée. Ils présentent également une fonction de hachage aléatoire pour partitionner l espace d états, qui ne fournit un bon équilibrage de charge que dans des conditions très précises. Leur outil de référence, Murphi, est populaire dans le milieu de la vérification de protocoles. Pour eux, le facteur limitant est le temps de calcul. Leurs travaux apportent surtout des solutions et des outils au problème majeur du temps d exécution pour la génération parallèle d espace d états, comme estimer l accélération par rapport au surcoût en communication, en utilisant les techniques de LogGP et d approximation de formule, réduire le surcoût de communication, par l agrégation de messages, et passer à des réseaux de machines NOW conventionnels, en traitant les problèmes de bande passante. Cependant, les données expérimentales reportées dans leur article concernent des espaces d états relativement petits (environ 1,5 Millions d états). Pour régler leur problème d équilibrage de charge, Nicol et Ciardo proposent une technique [NC97] qui équilibre automatiquement la charge. Bien que prometteuse, ils ne peuvent la valider que sur un petit modèle de états et souffrent d un large surcoût en communication. Un important atout de leur méthode est la fonction de partitionnement. Ils proposent des stratégies de repartitionnement et une méthodologie pour les utiliser. Par le choix de la fréquence de repartitionnement, on peut connaître quant il est nécessaire de repartitionner. Grâce à un interrupteur activé toutes les unités de temps Delta fixées par l utilisateur, on peut utiliser des points de synchronisation avec horloges réelles pour repartitionner chaque processeur. Leur technique de rééquilibrage introduite, vise à permettre la complétude de la charge du vecteur d état et de la charge de l émission par le processeur, ainsi que de la charge de réception. Knottenbelt et al. présentent dans [KH99] une génération probabiliste distribuée de Ctmc à partir de Spn. Les états y sont codés de manière efficace en utilisant des techniques de

40 40 Chapitre 2. La génération distribuée d espace d états hachage dynamique. Des collisions peuvent survenir et ne pas être détectées, entraînant une génération de seulement 99% du système, ce qui peut devenir un très gros problème pour les systèmes complexes. Leur article présente une des premières utilisations de techniques de stockage dynamique contrairement aux articles précédents et ils affichent une volonté déterminée à rendre obsolète les résultats jusqu alors trouvés en nombre d états générés (10 8,10 9 états). Ils définissent également en détail trois fonctions de hachage, l une pour le partitionnement des états sur les processeurs, et les deux autres dédiées au stockage des états durant la génération. Knottenbelt et Harrison ont écrit un autre article [KMHK98], pas axé sur la génération d espace d états, mais qui concerne l analyse parallèle de chaînes de Markov. Ils prétendent être les premiers à avoir résolu des modèles à plus de 50 millions d états et 500 millions de transitions. Ils effectuent une bonne utilisation de la capacité de stockage des disques durs et une optimisation intéressante de la multiplication parallèle de la matrice vectorielle éparpillée pour résoudre de manière distribuée de larges chaînes de Markov. Haverkort et al. présentent dans leur article [HBB99] la description de leur outil de génération distribuée de très grandes chaînes de Markov spécifiées par des Spn, incluant diverses techniques d optimisation, comme des techniques de codage des états. Ils y comparent deux produits (re)connus Spnp et Parsecs. Leur article est très complet et contient toutes les informations nécessaires à la compréhension de leur prototype. Avec l évolution des technologies, ils furent parmi les premiers à parler de l utilisation bénéfique, pratique, peu onéreuse, de grappes de stations de travail comme système Mimd, qui fournissent beaucoup plus de puissance de calcul qu une simple machine séquentielle. Un algorithme d exploration distribuée d espace d états [LS99] dérivé du model-checker SPIN [Hol97] a été implémenté pour le langage PROMELA. Leur algorithme est basé sur un parcours en profondeur d abord, mais reste dédié à des machines parallèles à mémoire distribuée. L un des facteurs limitant du modèle checker SPIN est la quantité de mémoire physique disponible. L algorithme obtient de bonnes performances sur des réseaux de machines homogènes et hétérogènes, mais il ne surpasse pas l implémentation séquentielle standard de SPIN, excepté pour des problèmes qui ne peuvent être stockés dans la mémoire principale d une seule machine. Plusieurs fonctions de partitionnement spécifiques à SPIN sont expérimentées, la plus avantageuse étant une fonction qui prend en compte seulement une fraction du vecteur d état. L article de Heyman [HGGS00] utilise une technique complètement transversale. Leurs travaux sont basés sur le remplacement par les Bdd des structures de donnée parallèles (Stornetta & Brewer), et sur la parallélisation des model-checkers explicites, tel que Murphi (Stern & Dill), mais en utilisant des méthodes symboliques, et des réductions d espace par partitionnement du travail en plusieurs tâches. Leur méthode présente des qualités concernant le passage à l échelle pour l analyse parallèle symbolique d accessibilité sur un environnement à mémoire distribuée de stations de travail et à communication par passage de message. Dans son dernier article [Cia01], Ciardo présente une synthèse sur les analyses distribuées de systèmes larges. Ils rediscute l importance de la fonction de partitionnement statique et

41 2.4. L évolution des méthodes : synthèse et discussion 41 fournie par l utilisateur, et celle du repartitionnement dynamique automatique. Cet article représente en fait un compte rendu de ses réalisations théoriques et pratiques. Il met alors en valeur ses résultats obtenus pour chaque méthode, et semble axer ses recherches vers l analyse symbolique d accessibilité distribuée sur un réseau de stations de travail. De cette étude bibliographique 1 sur la génération massivement parallèle d espace d états pour la vérification de systèmes, on peut retenir plusieurs points intéressants pour nos travaux. Les architectures parallèles à mémoire partagée semblent avoir été laissées de côté au profit des structures parallèles modernes telles que les grappes de Pc. Ce choix est justifiable en de nombreux points, parmi eux, le coût prohibitif des supercalculateurs. Cependant, des travaux récents [Ing00] continuent à essayer de tirer parti des machines multi-processeurs à mémoire virtuellement partagée, mais physiquement distribuée, telles que les Sgi Origin Leur justification d une telle approche est qu elle est plus pratique d utilisation, notamment puisqu elle ne fait pas appel aux techniques de programmation parallèles et distribuées. Elle reporte la difficulté de la distribution des données à celle de la synchronisation efficace d accès sur les données partagées. Ces avantages ne semblent pas justifier outre mesure le coût prohibitif de telles structures parallèles, pour la plupart inaccessibles, alors que chaque laboratoire de recherche possède au moins un réseau de stations de travail et que les grappes de machines deviennent de plus en plus conventionnelles et accessibles. Parmi les travaux référencés précédemment, très peu d entre eux mettent à la disposition du public leurs prototypes. A part la version parallèle de Murphi, aucun outil n est diffusé. Et les outils diffusés sont faits uniquement pour des modèles ou langages simples, voire des langages hautement spécifiques et seulement acceptés par leur plateforme. En l occurrence, le langage Murphi est le seul langage de spécification utilisé par l outil Murphi. Il y a donc un grand besoin de techniques de vérification parallélisées indépendantes du langage d entrée. L objectif de notre travail est également de mettre en œuvre la combinaison de techniques de génération parallèle d espace d états pour des langages de spécification capables de décrire des applications industrielles ayant des architectures logicielles complexes. De par nos recherches bibliographiques, nous en sommes arrivés à la conclusion qu aucune approche jusqu à présent ne traite les types de données dynamiques de manière distribuée dans un processus de vérification de systèmes. Nos travaux se proposent d introduire des méthodes et techniques de gestion des types de données dynamiques tels que les arbres, listes, graphes, et autres structures complexes. Au delà même de la génération distribuée d espace d états, les travaux présentés ici s inscrivent dans le but plus ambitieux de la parallélisation du langage Lotos et des 1 Pour une description exhaustive de chacune de ces approches, nous vous référons à notre matrice de comparaison des articles, présente en annexe A.

42 42 Chapitre 2. La génération distribuée d espace d états outils de vérification s y rattachant. Ces grands points conceptuels sur la génération distribuée d espace d états seront les fils directeurs des chapitres suivants, au cours desquels nous proposerons notre approche de génération distribuée, les différents avantages qu elle présente comparés à ceux extraits des outils de la littérature, et les aspects originaux qu elle recèle.

43 Chapitre 3 Les algorithmes Distributor et Coordinator Ce chapitre se propose d aborder la question théorique de notre approche du problème de la construction parallèle d espace d états. La section 2.1 indique le principe de fonctionnement que l on a adopté pour la génération parallèle d espace d états. La section 2.2 présente notre choix et notre justification de chacun des composants algorithmiques ou environnementaux de notre méthode. La section 2.3 propose des algorithmes permettant de traiter les spécifications contenant des types de données dynamiques, du type liste, arbre, ensemble, graphe, qui sont fréquemment présents dans les applications distribuées complexes. Nous présenterons plusieurs schémas de gestion des termes, et choisirons et définirons plus précisément un de ces protocoles pour une implémentation qui sera décrite dans le chapitre 5. Enfin, les sections 2.4 et 2.5 définissent nos algorithmes Distributor et Generator pour la génération parallèle d espace d états, en tenant compte de l ensemble des composants et des protocoles nécessaires à la construction du graphe. 3.1 Principe de fonctionnement Nous proposons des algorithmes de construction parallèle de systèmes de transitions étiquetées (Ste). Chaque machine est chargée de construire une partie du Ste sous forme d un fichier au format Bcg (Binary Coded Graphs), qui permet une représentation compacte du graphe. Un aspect original de notre système est la présence d un processus superviseur de la génération, un processus que l on pourrait qualifier de maître ou de père. Son rôle est multiple et fondamental dans la construction du graphe, et comprend notamment la collecte d informations locales à chacun des processus de la génération pour permettre le monitoring du système, un mécanisme d arrêt d urgence de l ensemble des processus suite à une panne ou un arrêt de l utilisateur, et des fonctionnalités spécifiques à la génération qui seront définies plus tard dans ce chapitre. Le fait est qu un ensemble de canaux de communication sont établis entre les processus fils et le processus père, selon un schéma en étoile, le père étant 43

44 44 Chapitre 3. Les algorithmes Distributor et Coordinator connecté à chacun des fils. La figure 3.1 illustre le mécanisme global de notre approche pour la génération distribuée de systèmes de transitions. Machine frontale programme compilateur Monitor superviseur (Coordinator) générateur (Distributor) générateur (Distributor)... générateur (Distributor) Grappe Bcg @N-1 Machine frontale fusion (Bcg Merge) Bcg Figure 3.1: Architecture des outils pour la génération distribuée d espace d états Cette figure définie l emplacement de chacun des processus participant à la génération, notamment la dispersion des processus générateurs sur chacune des machines de la grappe, dans le cas où on expérimenterait sur une grappe de machines, et le processus superviseur sur une machine appartenant ou non à la grappe. Une fois la génération terminée des fichiers Bcg partitionnés, il est possible de les fusionner en un fichier global représentant le système total de transitions étiquetées.

45 3.2. Désignation et association des composants Désignation et association des composants L objectif principal de notre travail était de combiner proprement et d étendre les techniques existantes pour la génération distribuée de l espace d états de systèmes modélisés formellement, indépendamment du langage utilisé. Dans nos travaux décrits par la suite, l idée acceptée est que l espace d états est très large et qu aucune technique de réduction ou de décomposition n est utilisée. L analyse se doit d être énumérative et non symbolique pour avoir une description exhaustive de l ensemble des états du graphe d accessibilité. Dans la sous-section 2.3.2, nous avons défini les composants globaux de la génération distribuée d espace d états. Nous précisons dans cette section, nos différents choix concernant ces composants Architecture parallèle support L approche que nous avons adopté vise à paralléliser la construction de l espace d états sur plusieurs machines, dans le but de bénéficier de toutes les mémoires locales et de toutes les ressources en Cpu de chaque machine. Ainsi, ce mécanisme permet de réduire à la fois la quantité de mémoire nécessaire sur chaque machine et le temps global d exécution. Le paradigme que nous utilisons, s inscrit dans celui de la programmation parallèle par passage de messages sur machines Mimd à mémoire physiquement distribuée et à plusieurs espaces d adressage. Notre méthode est donc sujette aux problèmes de partitionnement des tâches sur chacun des processeurs. Nos architecture cibles sont les réseaux traditionnels de stations de travail et les grappes de Pc. Nous avons préféré tirer bénéfice d architectures accessibles à moindre frais, disponibles et présentant de très bonnes performances, que d architectures coûteuses à mémoire logiquement partagée et limitées dans leur passage à l échelle Partitionnement des tâches Les états sont répartis entre les mémoires locales des machines au moyen d une fonction de hachage, déterminée statiquement, qui calcule pour chaque état s le numéro h(s) de la machine responsable du traitement et du stockage de l état s. Le choix de cette fonction est crucial pour obtenir un bon équilibrage de charge entre les machines. La fonction de hachage h(s) est définie par h(s) = (s mod P) mod N, où N est le nombre de processeurs, et P un nombre premier calculé en fonction de N. Si N est premier, alors P = N, sinon on choisit P tel que P mod N = 1. Cette fonction de hachage, bien que simpliste, présente de bonnes propriétés. Elle partage en N parties distinctes l espace d états. Au vue des expérimentations, elle équilibre également assez bien les charges entre chacun des processeurs. Cependant, aucun mécanisme de rééquilibrage automatique de charge n a été mis en place, donc ses performances varient selon les configurations. L un des problèmes majeurs des fonctions de hachage pour le partitionnement d un graphe est qu elles ne prennent pas en compte la localité des nœuds du graphe lors de leur partitionnement sur chacun des processeurs. Notre fonction a les mêmes limitations puisqu elle engendre beaucoup de transitions entre des nœuds n appartenant pas à la même partition, d où des communications importantes. Il

46 46 Chapitre 3. Les algorithmes Distributor et Coordinator est également à noter que cette fonction de hachage ne peut être utilisée que pour des machines homogènes, car le hachage est établi sur le vecteur de bits représentant l état, vecteur qui sera décrit différemment selon l architecture de la machine où la fonction est appelée. Ces limitations feront l objet de travaux futurs de ce projet de génération parallèle d espace d états, car trop spécifiques pour être traités dans le cadre de notre travail Structures de données requises Pour les états, qu ils soient explorés ou visités, nous avons décidé de les stocker dans une table de hachage. L avantage notable de n utiliser qu une seule table de hachage pour les deux ensembles V et E, est de ne pas avoir deux mécanismes de recherche et d insertion dans les deux ensembles d états, nécessaires lors de la génération (cf. chapitre 2, section 2.3.2). La fonction de hachage nécessaire au stockage des états est différente de celle utilisée lors du partitionnement des états sur les processeurs. Elle est basée sur s, vecteur de valeurs représentant l état, et sur la taille T de la table, et elle est implémentée en utilisant la bibliothèque de table d états fournie par l environnement Open/Cæsar. La structure des états s est un vecteur de bits sur lequel seulement une partie est hachable car canonique. La structure de la table de hachage également est différente. On alloue tout d abord une table de pages de taille fixée au départ de la génération, soit définie par l utilisateur, soit par défaut, et modifiable dynamiquement selon les besoins. En utilisant cette table de pages, on va allouer autant de pages de mémoire que nécessaires pour stocker les états rencontrés. La taille d une page est également un paramètre de la table. Lors de collisions, une chaîne se crée au sein d une même page, jusqu au prochain emplacement libre. Cette chaîne n est en fait que des redirections d indices d éléments présentes dans un item de la page. Une nouvelle page de table est créée, lorsque la page précédente est pleine. Ainsi la perte mémoire liée à des items non utilisés dans une page est infime. De plus, notre parcours en largeur d abord de l espace d états nous permet de stocker sans difficulté les ensembles d états explorés présents dans E et les états non encore traités présents dans V au sein d une même et unique structure de stockage en l occurrence notre table de hachage allouée dynamiquement. En effet, l organisation de la table est telle que, tous les états de l ensemble E se retrouvent au début de la table, et tous les états de l ensemble V se retrouvent juste après l ensemble E dans la table. Ainsi, les deux ensembles d états sont matérialisés distinctement, condition nécessaire au bon fonctionnement de l algorithme de génération, bien qu étant stockés sur la même structure. Dans la littérature, cette technique de hachage se rapproche de celle appelée hachage ouvert, sauf que nous ne créons pas de listes réellement chaînées mais des listes par redirection d indice Type de communication Les communications représentent le goulot d étranglement d un système réparti dont la programmation parallèle est basée sur du passage de messages. Deux types de programmation sont alors possibles pour combattre le surcoût engendré par la communication : la composition parallèle d automates reflétant le comportement du programme, ou méthode par

47 3.2. Désignation et association des composants 47 multi-threading, et la composition séquentielle d automates, ou méthode par ordonnancement statique ou encore par mono-threading. Le multi-threading est la meilleure approche pour permettre le recouvrement des communications par du calcul. Un thread est dédié aux communications tandis qu un autre thread se charge des calculs locaux. La principale difficulté est alors la synchronisation des deux threads sur les structures de données partagées, en l occurrence les ensembles d états et de transitions. La seconde approche ne permet pas un recouvrement aussi parfait de la communication par du calcul. Néanmoins, par une bonne connaissance du problème de la génération d espace d états, il est possible d ordonnancer et de gérer l ensemble des différents protocoles présents dans le programme afin de limiter au mieux les attentes liées à la communication, en permettant d effectuer des calculs locaux pendant les temps d attente. L implémentation de cette approche est également beaucoup plus facile à mettre en œuvre et à maintenir. Sa seule difficulté est donc l établissement de l ordre des différentes phases d opérations nécessaires à la génération distribuée du graphe d accessibilité. Pour ce qui est des modèles de programmation parallèle par passage de messages, plusieurs limitations étaient présentes dans l outil Distributor V2.0 au niveau de la communication. Une des améliorations majeures l outil est une optimisation des communications entre processus. Les communications représentent, dans le modèle par passage de messages, un sérieux goulot d étranglement dans le processus. Une attention particulière a été portée sur la conception des primitives de communication pour limiter au mieux le surcoût engendré par les nombreux messages échangés entre processus, et par la gestion locale des messages avant et après émission. Le modèle résultant est un modèle basé sur des sockets Unix non-bloquantes sur protocole Tcp/Ip réduisant la part de calcul nécessaire aux communications au maximum. Ce système de communication étant présent de manière native sur les systèmes d exploitation de type Unix, l outil bénéficie d une très grande portabilité, sans qu aucun logiciel supplémentaire n ait besoin d être installé. Ces mécanismes de communication ont fait l objet d une construction d une API clairement définie, séparant ainsi distinctement, dans le cadre de notre travail, l algorithme d exploration proprement dit, des aspects communication. Elle sera plus détaillée dans le chapitre 5 sur les réalisations et les expérimentations. Bien que présentant des avantages similaires à notre méthode de communication, nous n avons pas choisi d utiliser des modèles récemment standardisés comme Mpi (Message Passing Interface) [GHLL + 98], car ils impliquaient une lourdeur d installation qui n était pas l objectif de l outil Distributor destiné à être intégré à la boîte à outils Cadp. Notre but est que l utilisateur n ait à installer qu un seul logiciel, Cadp en l occurrence, pour que l outil soit fonctionnel. Le deuxième aspect négatif, et non des moindres, de tels standards est qu ils présentent des performances peu élevées comparées à la technique utilisant les sockets lorsqu elle est bien étalonnée. En effet, leur couche d abstraction est tellement généraliste, offrant tellement de possibilités qu elle en devient ralentie voire même limitée lorsque le nombre de processus est trop grand [CSG], d où une vitesse d exécution moins élevée qu avec

48 48 Chapitre 3. Les algorithmes Distributor et Coordinator des sockets. Enfin, nos algorithmes sont suffisamment simples pour ne pas avoir besoin des fonctionnalités de plus haut niveau fournies par Mpi Format de description du modèle à vérifier Le nombre de transitions étant très élevé, nous stockons les différents fichiers Bcg sur les disques durs locaux des machines. Nos algorithmes ont été développés en se basant sur les environnements génériques Bcg et Open/Cæsar [Gar98] qui permettent la manipulation de systèmes de transitions étiquetées depuis la boîte à outil de vérification Cadp [FGK + 96]. Étant donné que ces environnements sont indépendants du langage d entrée, nos algorithmes peuvent être directement utilisés non seulement pour le langage Lotos, mais aussi pour n importe quel langage connecté à l interface de programmation d application Open/Cæsar comme par exemple le langage Uml [BJR96] connecté au moyen de l outil Umlaut [JHGP99] développé à l Inria Rennes Terminaison distribuée La condition nécessaire pour que la construction du graphe prenne fin est que chaque machine ait traité tous les états qui lui sont attribués par la fonction de hachage, et que tous les canaux de communication entre les machines soient vides. La terminaison que nous avons choisi est dérivée de celle de Mattern [Mat87], et est détectée au moyen d un algorithme réparti à base d anneau virtuel à jeton. Nous avons également étudié d autres algorithmes de terminaison distribuée. Une de nos études a porté sur le choix entre une structure en anneau ou une en étoile pour détecter la terminaison, et de manière plus générale sur l introduction ou non du processus superviseur dans le protocole de terminaison. Le but est de diminuer le nombre de tentatives de détection de terminaison par le système, et par suite le coût en communication lié au protocole de terminaison. Un autre objectif est de faciliter la correction des protocoles et d avoir, dans nos algorithmes, des protocoles plus fiables, comme la détection de terminaison, en intégrant le processus superviseur dans chacun d eux, car ce processus est déjà impliqué dans la majorité de ces protocoles. Notre conclusion concernant la terminaison distribuée est la suivante. La terminaison utilisant une architecture en anneau virtuel semble meilleure que celle utilisant une architecture en étoile, telle que la diffusion par le superviseur, après réception d information sur le système. En effet, le problème de la terminaison distribuée est d obtenir une représentation du status global d un système à un instant donné. Or, à cause du caractère distribué de ce système, les informations concernant le système sont réparties entre les différentes machines et doivent être véhiculées par les canaux de communication inter-processus. Ces informations peuvent, en conséquence, ne pas être immédiatement transmises, d où le problème de ne pas avoir une vision à jour du système une fois les informations reçues. Le mécanisme des deux vagues établis par Mattern, permet de contrer ce problème, en cherchant à visualiser l évolution des canaux. Par contre, vouloir obtenir une vision précise à un instant donné du système

49 3.2. Désignation et association des composants 49 par simple demande d information par le superviseur à chacun des processus générateurs, ne peut pas répondre à ce problème, même si le processus superviseur est le processus ayant la vision du système la plus à jour. C est pourquoi, une solution utilisant une architecture en étoile risque de ne convenir qu au prix de communications, et donc d envois de messages, supplémentaires, comme pour effectuer une deuxième vague, par rapport à une solution en anneau virtuel, et la rend donc non-satisfaisante. De même, vouloir intégrer le processus superviseur sur l anneau virtuel, n apporte aucun bénéfice à la génération globalement, si ce n est de rajouter des communications supplémentaires inutiles. C est pourquoi nous pensons que le protocole de terminaison distribuée ne devrait pas faire intervenir le processus superviseur, et devrait utiliser une architecture en anneau Type de vérification La génération de notre graphe d accessibilité conduit à la construction d un système partitionné de transitions étiquetées, représenté par une collection de fichiers au format Bcg (Binary Coded Graphs). Chaque machine, participant à la génération, est chargée de construire une partie du graphe sous forme de fichier dans ce format Bcg, format qui permet une représentation compacte mais complète du graphe. Notre système est donc basé sur une analyse parallèle énumérative de l espace des états du système, et non pas une analyse parallèle symbolique. L étape suivante consiste à fusionner ces fichiers Bcg en un seul fichier Bcg que l on pourra utiliser avec tous les outils de vérification de Cadp, des outils basés sur des bisimulations ou du µ-calcul modal. Cette fusion peut se faire par l outil Bcg Merge en l utilisant sur les fichiers Bcg que l outil Distributor aura créé sur chacune des machines. Nous ne décrirons pas le mécanisme de Bcg Merge ici, mais noterons quand même que la fusion des différents fichiers Bcg est possible grâce à l outil Distributor qui permet une numérotation unique, sur l ensemble des machines, de chacun des états du graphe. La phase de vérification de larges espaces d états de systèmes générés parallèlement est ainsi rendue possible par cette technique de fusion de graphes partitionnés Performances de la technique L analyse de performance de notre outil fait l objet du chapitre 5, mais nous pouvons d ores et déjà dire que les accélérations obtenues sont proches d être linéaires en nombre de machines utilisées. Ces résultats expérimentaux seront replacés dans le contexte de notre fonction de partitionnement des états entre les processeurs, et celui de notre méthode de communication, car ils influent énormément sur les temps de calcul. Ainsi, d après la description de chacun des composants algorithmiques de l outil de génération, nous pouvons souligner le fait que notre approche du problème est originale par rapport aux travaux que l on trouve dans la littérature. Elle est originale non pas par les différentes techniques qu elle utilise, mais par la combinaison adaptée de techniques perfor-

50 50 Chapitre 3. Les algorithmes Distributor et Coordinator mantes créant en résultat une solution complète, de la génération du graphe d accessibilité, à la vérification de propriétés sur cet espace d états. Nous allons voir par la suite comment nous complétons davantage notre génération parallèle d espace d états, notamment par l introduction d un protocole permettant l utilisation de données dynamiques dans les états du graphe. 3.3 Le protocole de cohérence des termes et des labels Nos études menées au cours de cette année n apportent pas une révolution des techniques d analyse d accessibilité de modèles formels, elles amènent néanmoins un composant nouveau, encore jamais développé dans la littérature qui nous a été permis de consulter. Il s agit d une extension du traitement parallèle des types de données basiques, tels que les booléens et les entiers, à celui des données de type dynamique, telles que les listes, arbres, ensembles, graphes et structures complexes. Ces types de données sont présents dans la plupart des langages formels de haut niveau comme Lotos. L utilisation parallèle sur machines distribuées de telles données n est pas une tâche triviale, car ces types de données sont basés sur des pointeurs qui n ont de sens que localement à une machine. Nous allons développé dans ce chapitre plusieurs solutions à ce problème, et justifier le choix de la méthode qui sera gardée en premier lieu pour une intégration à l outil Définition du problème Lors de la génération distribuée du Ste, les machines sont amenées à échanger des transitions par les canaux de communication, transitions qui mènent à des états dont elles ne sont pas responsables de l exploration. Ces états sont des vecteurs de valeurs qui peuvent être de type dynamique. Pour pouvoir utiliser des types de données dynamiques, il nous faut répondre à deux sous problèmes : quel format utiliser pour rendre ces données utilisables sur différentes machines connectées par réseau, et comment rendre cohérente la création de nouvelles données localement à une machine sur l ensemble des machines? La transmission directe des pointeurs entre processeurs est impossible à cause de l incohérence des objets pointés. Une solution consiste à coder de manière canonique les objets pointés, et de transformer les structures complexes en tuple d objets ainsi obtenus. Cette représentation canonique peut se faire par l attribution d un numéro unique à chaque nouvelle cellule mémoire allouée dynamiquement. Les composants d un état peuvent se séparer en deux parties : différents constructeurs de taille constante en première partie de l état, comme les valeurs de type booléen, entier, etc., formant la clef de hachage pour la fonction de partitionnement, et une deuxième partie formée de pointeurs vers des structures complexes de type dynamique (liste, arbre, graphe, etc.). La partie hachable est la première partie, car l état contient des pointeurs dans le reste de sa description, qui n ont de sens que localement à un processeur. Les pointeurs sont des

51 3.3. Le protocole de cohérence des termes et des labels 51 données de l état qui ne sont pas canoniques. Nous appelons terme, ou valeur, toute donnée qui compose un état. Les termes sont des parties d états, ou encore des constructeurs d états. Dans Lotos, un terme consiste en la construction par cons de tuples de valeurs, l opération cons ayant la même signification que malloc pour définir des structures de données. La syntaxe utilisée est cons(a, cons(b, c)), pour définir une cellule composée d une valeur a et d une cellule contenant b et c. La modification d un terme entraîne la modification de l état dans lequel il est présent. La figure 3.2 montre la structure d une transition (S 1,l,S 2 ), où S 1 est représenté par un entier l identifiant, l est le label dont on parlera dans la partie qui suit, et S 2 est le vecteur d état qui peut être composé de constructeurs à taille constante comme des int ou des bool, et de données de type dynamique comme cons(a1,a2) ou cons(b1,b2). b1 b2 n i (s) l int bool cons(a1,a2) cons(b1,b2)... S1 Label S2 a1 a2 Figure 3.2: Description d un type de transition du Ste, et de l état S2, comportant deux termes de type dynamique Une autre structure à la base des transitions est le label, appelé également action, qui indique l opération qui est à l origine du changement d état et donc de la transition. Le problème lié au label est sensiblement différent de celui des termes. Les labels sont des chaînes de caractères ou encore des chaînes de bits de taille variable, qui doivent être échangées entre processeurs lors d envoi de transition. Dans le cas de chaînes de bits le problème est identique à celui des termes, mais dans le cas des chaînes de caractère, le problème est l envoi massif de messages pouvant avoir des longueurs importantes et variables, et entraîner une grande surcharge du réseau. Rendre canonique les labels permettrait des gains énormes en communication. La figure 3.3 présente le problème de la taille variable des labels, en prenant pour exemple un label a, pouvant être extrait du langage Lotos, défini par une porte de synchronisation G et des valeurs v 1, v 2,..., v n échangées à travers cette porte.

52 52 Chapitre 3. Les algorithmes Distributor et Coordinator ig iv 1... iv n a Figure 3.3: Label a = (G,v 1,v 2,...,v n ) Le second problème, alors soulevé, est de rendre cohérents les numéros uniques correspondants aux termes et aux labels, ce qui revient à vouloir rendre canoniques les transitions échangées sur le réseau, pour n envoyer que des numéros uniques à la place, et pouvoir faire du hachage sur l état entier. Pour ce faire, nous avons étudié différents protocoles de cohérence des termes et des labels, permettant de rendre canoniques les données de type dynamique tout en veillant à ne pas avoir de copies multiples des mêmes objets dans la mémoire. Le mécanisme de stockage des termes ou des labels est le même que pour celui des états. On utilise une table de hachage répartie en plusieurs pages que l on alloue dynamiquement. Le protocole de cohérence met en œuvre une insertion cohérente répartie des termes et labels dans les tables Analyse de protocoles Nous décrivons par la suite deux approches et quatre protocoles qui résument les différentes possibilités de cohérence de manière distribuée ou centralisée des termes et des labels. Le protocole de cohérence des labels n étant qu un cas particulier de celui des termes, en l occurrence un objet de taille dynamique, nous ne décrirons, par souci de lisibilité, que les protocoles pour la cohérence des termes, sachant qu ils fonctionnent aussi bien pour des termes que pour des labels. Choix entre approche bloquante ou non-bloquante L invariant que l on cherche à définir ici est de savoir si les différentes machines ont les mêmes numérotations des termes, ou bien, si chaque machine a des pointeurs locaux sur ces termes, ajoutés à des index globaux pour communiquer avec l extérieur. Pour répondre au premier invariant, l approche, dite bloquante, est nécessaire. Dans cette approche, la découverte d un nouveau terme nécessite une coordination entre tous les processus pour déterminer un numéro unique pour ce terme. Tant que la machine n a pas reçu ou ne connaît pas le numéro unique du terme en question, elle reste bloquée en attente d une réponse. Le deuxième invariant implique une approche dite non-bloquante car la machine qui découvre un nouveau terme, lui alloue directement un pointeur local pour répondre immédiatement à son besoin pour ses calculs locaux. Seulement, pour que ses termes aient un sens sur une autre machine, il est également nécessaire d avoir une coordination entre toutes les machines pour donner aux termes des index globaux uniques connus de tous, pour pouvoir communiquer

53 3.3. Le protocole de cohérence des termes et des labels 53 avec l extérieur. Cet index sera utilisé lors des envois de messages de processus à processus. Cette deuxième approche présente l avantage de ne pas bloquer une machine sur un nouveau terme jusqu à réception de son numéro unique. Elle est dans ce sens d un moindre surcoût pour la génération de l espace d états. Cependant elle est intrinsèquement beaucoup plus compliquée à gérer et à maintenir. En effet, elle oblige à une double numérotation pour chacun des termes, et une mécanique complexe de mise à jour des références sur un terme dont on veut le numéro, terme qui a pu être, entre temps, référencé par de nombreux autres termes. Pour ces surcoûts en mémoire et en temps de calcul, nous avons préféré l approche plus simple mais bloquante respectant le premier invariant uniquement. Différents protocoles basés sur l approche bloquante De cette approche bloquante, nous pouvons explicité plusieurs protocoles de cohérence des termes qui se différencient essentiellement par leur aspect centralisé ou distribué. Les protocoles centralisés 1 et 2 font intervenir le processus superviseur, et ont entre autres pour invariant que le superviseur contient les tables de termes les plus à jour. Les protocoles distribués 3 et 4 ont pour invariants principaux, l exclusion totale du superviseur du protocole de cohérence et la garantie que le même terme a toujours le même numéro partout. Il s agit une fois de plus, comme dans le cas de la terminaison distribuée, d étudier les différentes configurations en anneau ou en étoile intégrant ou non le processus superviseur. Protocole 1 : Modèle client-serveur Ce protocole ressemble aux approches dites lazy, dans le sens où seuls les acteurs de requêtes reçoivent une réponse du superviseur. Son mécanisme global est simple et constitue son principal avantage. Lorsqu un processus générateur découvre un nouveau terme, il cherche à obtenir son numéro unique en lançant une requête contenant le terme au processus superviseur. Le superviseur lui renvoie l index, correspondant à la position où il a inséré le terme dans sa table, au processus générateur ayant fait la requête. Celui-ci sur réception de la réponse, insère le nouveau terme dans sa table en lui associant l index renvoyé par le superviseur pour numéro unique. Un inconvénient de cette technique est qu elle résulte en des tables de termes hétérogènes entre tous les processus générateurs, car ils n insèrent pas les différents termes en même temps. Les autres processus fils, lorsqu ils découvriront le même terme, devront à leur tour en faire la demande au superviseur qui leur renverra le même index qu il aura envoyé au premier fils en ayant fait la demande. Le coût associé à un terme nouveau dans ce protocole est entre 2 et 2N messages. Le minimum est atteint lorsque seulement 1 générateur a besoin du nouveau terme. Le maximum l est lorsque tous les processus générateurs doivent utiliser ce nouveau terme. Nous avons constaté expérimentalement que chacun des termes rencontrés par un fils est utilisé dans la plupart des processus fils du système. Ce protocole a donc un coût qui reste proche du maximum, en plus d un surcoût mémoire pour les index des termes. Protocole 2 : Modèle événement-réaction Le processus superviseur se comporte comme un serveur centralisé de termes ou de labels. Un groupe de processus clients, les pro-

54 54 Chapitre 3. Les algorithmes Distributor et Coordinator cessus fils, peuvent communiquer par messages avec ce serveur selon un modèle événementréaction. En effet, on peut voir les processus fils comme formant un groupe fils qui se serait abonné au service découverte d un nouveau terme. Lorsqu un fils découvre un nouveau terme, il le publie, c est à dire il l envoie à une boîte aux lettres unique, ici le serveur représenté par le superviseur. Après le dépôt par le processus fils du nouveau terme sur le processus superviseur, tous les processus générateurs sont informés par ce dernier et exécutent une réaction pré-définie, en l occurrence la mise à jour de leur table de termes ou de labels. La manière dont les processus générateurs sont informés par le superviseur est représentative du type de cohérence entre toutes les tables et du type d informations nécessaires à véhiculer dans les messages et les tables. Le mécanisme le plus adapté pour la transmission par le superviseur de l information concernant le nouveau terme ou le nouveau label est la diffusion, ou broadcast, de l information vers tous les processus générateurs au même instant. Les avantages de ce mécanisme sont multiples : La découverte d un nouveau terme entraîne un coût minimal de N +1 messages, répartis en 1 message envoyé par le fils, qui a découvert le terme, au processus superviseur, et en N messages (broadcast) du superviseur vers les processus fils pour les informer du nouveau terme. La borne maximale est 2N si tous les processus générateurs découvrent au même instant le nouveau terme, et qu ils ont le temps d envoyer leur message de découverte avant de recevoir la réponse du superviseur pour ce nouveau terme. Le superviseur ignorera simplement les requêtes, si elles concernent un terme qu il a déjà traité, car il a dû faire une émission simultanée du terme vers tous les processus générateurs lors de la réception de la première requête concernant ce terme. Les communications étant considérées comme fiables et FIFO, tous les processus générateurs ont dû recevoir ou recevront prochainement du superviseur, et dans le même ordre, le terme en question à mettre dans leurs tables. Si le mécanisme de réponse du superviseur est rapide, de telles situations ne devraient se produire que rarement, et le coût devrait rester proche de N + 1. En émettant simultanément le nouveau terme à tous les processus générateurs en même temps, le superviseur impose, en quelque sorte, un ordre unique d insertion des nouveaux termes dans les tables des processus générateurs. Le superviseur peut être considéré comme un ordonnanceur et régulateur d insertion des termes nouveaux dans les tables des processus générateurs. La cohérence entre toutes les tables de termes de tous les processus générateurs est ainsi totale, car les tables sont identiquement remplies et au même instant. L avantage majeur de cette technique est que toutes les tables sont homogènes car identiques. Nous rappelons que le but de ce protocole est de pouvoir rendre canonique des termes et des labels pour pouvoir n envoyer que des identifications de taille fixe de ces entités sur le réseau entre les processus générateurs lors de la génération de l espace d états. Un moyen de les rendre canoniques est de donner des numéros uniques à chacun de ces termes. En imposant un ordre d insertion séquentielle unique des nouveaux termes dans les tables de termes des processus générateurs, le superviseur n a plus besoin

55 3.3. Le protocole de cohérence des termes et des labels 55 d envoyer de numéros uniques associés avec ces termes puisque l index de ces entités dans la table de termes les stockant, est lui aussi unique. Une conséquence directe de notre mécanisme est une diminution de la taille des messages échangés sur le réseau. En résultat, par ce protocole, on obtient une homogénéité des tables de termes entre les processus générateurs et le superviseur. La version la plus à jour de ces tables est toujours celle du processus superviseur. Toutes ces tables étant identiques, le numéro unique correspondant au nouveau terme est l index de ce terme dans n importe quelle table de termes parmi tous les processus. Chaque fils a un accès direct à l information canonique des termes découverts jusque là par lui-même ou par d autres processus fils. Protocole 3 : Modèle élection distribuée Étant donné que la centralisation des requêtes vers le superviseur risque de présenter un goulot d étranglement, le processus superviseur ne devrait plus faire partie du processus de cohérence. Le problème de la cohérence des termes peut alors se résumer à trouver un ou plusieurs processus qui auront la charge de donner les numéros uniques pour les termes. Une solution serait de centraliser les requêtes vers un processus fils déterminé à l avance. L avantage serait un mécanisme simple de cohérence comme ceux présentés précédemment. Seulement, cette méthode constituerait également un goulot d étranglement sur ce processus ralentissant globalement la génération, car le processus serait surchargé de requêtes concernant les termes et les labels. Cette solution n est donc pas très satisfaisante. Une autre consiste à répartir la gestion de ces termes sur tous les processus, soit en faisant une élection du processus responsable du terme, soit en hachant le terme pour connaître le responsable. Le mécanisme d élection peut se résumer de la manière suivante. Quand un processus fils découvre une nouvelle valeur, il se propose candidat pour numéroter cette valeur. On fait alors une élection de type leader election, sur un anneau virtuel pour déterminer quel processus parmi les processus candidats va être élu pour donner un index unique. Une manière de donner un index unique pour un terme donné est de créer un couple de valeur (processeur, numéro unique). Le problème de l élection est de définir un critère de priorité différenciant deux requêtes pour un même terme venant de deux processus fils différents. Parmi les critères possibles, on peut trouver l ordre croissant ou décroissant des numéros identifiant un processeur, l ordre croissant ou décroissant du nombre de termes dont un processeur a eu la responsabilité, etc. Une fois l élection terminée, le processus élu renvoie sur l anneau le terme et l index qu il lui a attribué, à tous les autres processus. Le coût de ce protocole est constant, égal à 2N, soit N messages pour l élection du processus leader et N messages pour l émission de la réponse et pour les mises à jour des tables des processus fils. Protocole 4 : Modèle élection par hachage Dans la méthode précédente, l élection du processus responsable d un terme est une opération coûteuse en nombre de messages. De plus, elle n offre pas un très bon équilibrage de charge si le critère de priorité choisi est celui de l ordre sur les numéros de processeurs, car favorisant soit les processeurs de plus petit numéro, soit ceux de plus grands numéros selon l ordre choisi. A la place d élection, on pourrait également faire du hachage pour choisir le processeur qui

56 56 Chapitre 3. Les algorithmes Distributor et Coordinator sera responsable du terme V en cours de traitement. Les processus découvrant ce terme, demandent alors au processus responsable le numéro unique identifiant le terme. Les problèmes de répartition des charges de calcul sont liés à la fonction de hachage elle-même. Concernant le numéro unique, la même technique que précédemment peut être utilisée, à savoir le couple de valeurs (numéro de processeur, numéro unique choisi). Le coût est alors entre N et 2N si l on décide de faire diffuser le terme et son numéro unique par le processus qui en est responsable. Le processus responsable émettra simultanément le terme à tous les processus générateurs, en réponse à une requête venant d un autre processus ou lors de la découverte du nouveau terme par le processus responsable lui-même. Comme pour le protocole centralisé sur le modèle client-serveur, toutes les tables de termes ne sont pas homogènes entre elles. Certaines entrées de ces tables doivent également contenir des redondances d information car devant stocker à la fois le terme et son index unique, composé lui-même d un numéro de processeur et d un numéro unique. Ces spécificités font que la recherche de terme ou de numéro unique de terme, après terminaison de ce protocole, est une tâche coûteuse car complexe. Discussion et choix d un protocole Les protocoles distribués, comme 3 et 4 entraînent un surcoût en mémoire car ils ont besoin de stocker explicitement le numéro unique du terme avec le terme dans leur table de termes, et également un surcoût en calcul pour identifier le processus responsable de ce terme. Une surcharge du réseau est prévisible au vu du nombre de messages nécessaires pour permettre la cohérence pour chacun des termes employés. Les processus eux-mêmes seront surchargés, car ils doivent s occuper en parallèle de générer l espace d états, une génération très demandante en calculs. De manière générale, dans tous les protocoles sauf le protocole 2, la question de la mise à jour des références sur un terme dont on veut le numéro unique reste ouverte. En effet, elle implique une mécanique très complexe basée sur l utilisation des couples de valeurs représentant le numéro unique du terme, et sur les conséquences de modifications sur le terme, pouvant éventuellement être lié à d autres termes, notamment lorsqu un terme est une composition de plusieurs termes. Si on se borne aux critères d efficacité en nombre de messages échangés, le modèle clientserveur est celui présentant la borne inférieure la plus basse. Mais dès que les termes sont globalement utilisés par tous les processus, le modèle événement-réaction reste l un des plus performants. Un autre critère est celui du nombre d opérations de recherche et insertion nécessaire lors de l utilisation de chacun de ces protocoles et après réception du numéro unique. La structure impliquée par le protocole 2 fait que ces mécanismes de recherche et insertion sont simples et efficaces, car toutes les tables de termes sont identiques entre elles sur chacun des processeurs. Pour ces raisons, nous ne garderons pas la solution des protocoles de cohérence 1, 3 et 4 ni pour les termes ni pour les labels. Ainsi, nous avons choisi le protocole 2 basé sur le modèle événement-réaction car il offre à la fois simplicité de mise en œuvre, facilitant par là même

57 3.4. L algorithme Distributor 57 sa correction, et faible surcoût en communication et en charge de calculs. Ce protocole est utilisé aussi bien pour rendre canoniques les termes que pour rendre canoniques les labels en tirant partie du processus superviseur. La difficulté restante est l intégration de ce protocole pour les termes et pour les labels avec le reste de la génération et avec l environnement logiciel que forme Cadp dans lequel il devra évoluer, une intégration qui sera discutée dans la partie réalisation du chapitre 5. Ainsi, lors de la découverte d un état ne lui appartenant pas, une machine est capable d envoyer sur le réseau le tuple de termes canonisés représentant l état, à une autre machine qui pourra retrouver la structure de l état grâce à sa table de termes. Le principe est le même pour les labels au sein de transitions échangées entre machines. Seul le numéro unique identifiant le label sera envoyé, et la machine réceptrice de la transition sera capable de retrouver, en utilisant le numéro unique comme index dans sa table de labels, la chaîne de caractères ou label représentant le numéro unique. 3.4 L algorithme Distributor Le mécanisme général de la méthode de génération distribuée du graphe d accessibilité consiste à rajouter globalement deux phases d opérations aux trois phases expliquées précédemment dans le cadre de la génération séquentielle (cf.2.1). On ajoute une phase de réception de messages avant les phases d extraction, de génération et de recherche/insertion. Puis on conclut l itération par une phase d émission de messages. Nous avons décidé d adopter le paradigme maître-esclave, ou master-slave, qui est l approche la plus appropriée pour construire le graphe d accessibilité si l on veut contrôler les flux de travail de chacun des nœuds dans une machine Mimd. Le processus maître ne gère pas l ensemble des états créés, mais seulement des besoins d information concernant les transitions et états trouvés par les nœuds esclaves. L introduction de ce processus auxiliaire a été mise en place suite, notamment, à un besoin d avoir un processus qui soit responsable du lancement des processus de génération répartis sur chacune des N machines et du lancement de l outil Bcg Merge V2.0 après terminaison de la génération distribuée. Le rôle du processus superviseur, a d avantage d importance, car sa place est fondamentale dans de nombreux protocoles mis en œuvre dans notre approche de la génération distribuée de l espace d états. Son fonctionnement a fait l objet de l établissement d un nouvel algorithme, appelé Coordinator, que l on développera dans la prochaine section. Ajouté au protocole de la construction distribuée du graphe, nous avons défini quatre autres protocoles à faire coopérer et à gérer dans nos algorithmes : La détection distribuée de la terminaison La visualisation ou monitoring du système

58 58 Chapitre 3. Les algorithmes Distributor et Coordinator La détection de pannes et les arrêts d urgence La cohérence des labels et la cohérence des termes Seulement deux de ces protocoles, à savoir la construction distribuée du graphe et la détection distribuée de terminaison, restent indépendants du processus superviseur de par leurs aspects distribués et simplement parce que le superviseur ne leur apporte rien de bénéfique, si ce n est un surcoût en communication et en temps de calcul (exemple typique de la terminaison distribuée selon les solutions proposées dans la section 3.1). Ces protocoles font intervenir les processus fils à différents niveaux dans la génération distribuée, et forment l algorithme Distributor (cf. fig 3.4 à 3.7). Nous nous proposons de décrire chacun de ces protocoles dans les parties qui suivent, en séparant distinctement chacun d eux et en justifiant leur ordre d exécution dans l automate mono-thread qui en résulte Construction de l espace d états partitionné Nous considérons un réseau de N machines numérotées de 0 à N 1 et un Ste M = (S,A,T,s 0 ) donné implicitement par son état initial s 0 S et sa fonction calculant les successeurs succ. S est l ensemble des états identifiés par des numéros uniques sur l ensemble des processus. A est l ensemble des actions et T S A S est la relation de transition. Une transition (s,a,s ) T indique que le système peut passer de l état s à l état s en effectuant l action a. Tous les états dans S sont supposés être accessibles depuis l état s 0 à travers une succession de transitions dans T. Chaque machine exécute une instance de l algorithme de génération parallèle Distributor montré sur la figure 3.4, qui fait une exploration (partielle) en avant de M et produit un composant Ste B i = (S i,a i,t i ) stocké dans un fichier Bcg. L ensemble S i des états est construit par la machine i déterminée en utilisant la fonction statique de partitionnement h : S [0, N 1]. Cet ensemble est définie par S i = {s S h(s) = i}, qui détermine aussi les ensembles T i et A i selon les définitions énoncées ci-dessus. Ajouté à ces N processus, nous modélisons une machine de numéro N qui est celle du processus superviseur, exécutant l algorithme Coordinator(cf. fig 3.8). La machine i garde dans sa mémoire locale les états de S i, alors que les transitions de T i sont écrites dans le fichier Bcg stocké sur le disque local à la machine. Les états visités et explorés par la machine i sont stockés dans les deux ensembles disjoints V i et E i. Pour pouvoir effectuer la fusion des fichiers Bcg par l outil Bcg Merge, les états de S i sont numérotés modulo i. La machine i peut envoyer un message m à la machine j en invoquant la primitive nommée Send(j, m) et peut recevoir un message en invoquant une autre primitive Receive(r, m, k), où r est un filtre pour la réception de messages sur un ensemble spécifique de machines, et où k est l émetteur du message. r peut être un filtre n acceptant que les communications entre les processus générateurs et superviseur, ou bien acceptant toutes les communications. Il y a onze sortes de messages, que l on peut regrouper en cinq catégories, représentées par des lettres dans l algorithme. Les messages concernant la construction du graphe, ou

59 3.4. L algorithme Distributor 59 procedure Distributor (in i, s 0, monitor, h, N; out S i, A i, T i ) is initiator i := (h(s 0 ) = i); E i := ; A i := ; T i := ; c i := i; monitorstatus i := Nrm; coordinator := N; Any i := {0.. i 1} {i N} if initiator i then n i (s 0 ) := c i ; V i := {s 0 }; S i := {n i (s 0 )} termstatus i := Rec ; totalrecd i := 0; totalsent i := 0 else V i := ; S i := ; termstatus i := Nrm endif; nbsent i := 0; nbrecd i := 0; recvfrom i := Any i ; transexplo i := true; stateexplo i := true; canonicstatus i := Nrm while termstatus i Stop do if termstatus i Emg then if InternalError() then (E) termstatus i := Emg elsif monitorstatus i = Nrm then if Receive (recvfrom i, m i, sender i ) then case m i is Arc(n,l,s) a := label(l, A i ); if a A i then (T) (A) (C+A) else if s E i V i then c i := c i + N; n i (s) := c i ; V i := V i {s}; S i := S i {n i (s)} endif; T i := T i {(n,a,n i (s))}; nbrecd i := nbrecd i + 1; monitorstatus i := Stats endif Rec(k) totalrecd i := k if initiator i then termstatus i := Rec else termstatus i := Snd endif msgarc i := (n, l, s); recvfrom i := {coordinator} Figure 3.4: Génération parallèle d un système de transitions étiquetées: réception des messages de transition (A), ou de terminaison (T), et détection de pannes (E)

60 60 Chapitre 3. Les algorithmes Distributor et Coordinator (G) (T) Snd(k) totalsent i := k if initiator i then termstatus i := Snd elsif totalrecd i = totalsent i then termstatus i := End else termstatus i := Rec ; totalrecd i := 0; totalsent i := 0 endif End termstatus i := End Lab(a) A i := A i {a}; (C) (C+A) if (canonicstatus i = Rec) (a = newlabel i ) then canonicstatus i := End; recvfrom i := Any i endif ind := index(a, A i ) for (n,l,s) msgarc i do if (l = ind) then if s E i V i then c i := c i + N; n i (s) := c i ; V i := V i {s}; S i := S i {n i (s)} endif; T i := T i {(n,a,n i (s))}; nbrecd i := nbrecd i + 1; recvfrom i := Any i endif endfor Emg termstatus i := Stop (E) endcase elsif (V i ) (canonicstatus i Rec) then if transexplo i then if stateexplo i then choose s V i ; V i := V i \ {s}; E i := E i {s}; stateexplo i := false; endif if transsucc(s) then (C) if canonicstatus i = Nrm then (a,s ) = succ(s); newlabel i := a if a A i then l := index(a,a i ); canonicstatus i := End; Figure 3.5: Génération parallèle d un système de transitions étiquetées: réception de messages de terminaison (T), de messages envoyés par le coordinator pour le protocole de canonisation (C et C+A) et d arrêt d urgence (E), et construction du graphe (G)

61 3.4. L algorithme Distributor 61 (G) (C) else canonicstatus i := Lab; if SendFlush (coordinator, Lab(newLabel i )) then canonicstatus i := Rec; recvfrom i := {coordinator} endif endif elsif canonicstatus i = Lab then if SendFlush (coordinator, Lab(newLabel i )) then canonicstatus i := Rec; recvfrom i := {coordinator} endif endif if canonicstatus i = End then transexplo i := false; l := index(newlabel i, A i ); canonicstatus i := Nrm if h(s ) = i then if s E i V i then c i := c i + N; n i (s ) := c i ; V i := V i {s }; S i := S i {n i (s )} endif; T i := T i {(n i (s),newlabel i,n i (s ))}; transexplo i := true; monitorstatus i := Stats elsif Send (h(s ), Arc(n i (s),l,s)) then transexplo i := true endif endif else stateexplo i := true; endif elsif Send (h(s ), Arc(n i (s),l,s)) then transexplo i := true endif else case termstatus i is Figure 3.6: Génération parallèle d un système de transitions étiquetées: construction du graphe (G) et canonisation des labels (C)

62 62 Chapitre 3. Les algorithmes Distributor et Coordinator (E) (T) Nrm monitorstatus i := Trm Rec if SendFlush ((i + 1) mod N, Rec(totalRecd i + nbrecd i )) then termstatus i := Nrm endif Snd if SendFlush ((i + 1) mod N, Snd(totalSent i + nbsent i )) then termstatus i := Nrm endif End if SendFlush ((i + 1) mod N, End) then monitorstatus i := End endif endcase endif else case monitorstatus i is (M) endcase else endif endwhile end Stats if monitor SendFlush (coordinator, Stats(T i )) then monitorstatus i := Nrm endif Trm if monitor SendFlush (coordinator, Trm) then monitorstatus i := Nrm endif End if initiator i then if SendFlush (coordinator, Init) then monitorstatus i := Stop endif else monitorstatus i := Stop endif Stop if (monitor SendFlush (coordinator, Stop(T i ))) ( monitor SendFlush (coordinator, Visit(T i ))) then termstatus i := Stop endif if SendFlush (coordinator, Emg) then termstatus i := Stop endif Figure 3.7: Génération parallèle d un système de transitions étiquetées: terminaison distribuée (T), monitoring du système (M) et arrêt d urgence (E)

63 3.4. L algorithme Distributor 63 (G), sont des messages de type Arc qui sont utilisés pour la transmission de transitions du Ste. Ceux pour la terminaison distribuée, ou (T), sont Rec, Snd et End. Les messages Stats,Stop,Trm,Init et V isit sont utiles pour la visualisation de données statistiques, ou (M), concernant la génération. Les messages Lab sont nécessaires pour la représentation canonique des labels, ou (C). Enfin, les messages Emg nous permettent la détection de pannes, ou (E). Les primitives Send et Receive sont supposées être non-bloquantes. Elles retournent en résultat un booléen indiquant si le message a bien été émis, respectivement reçu. La construction du graphe est commencée par la machine appelée initiator, ayant pour index h(s 0 ) = i, qui explore l état initial du Ste. L algorithme Distributor consiste en une boucle englobante, qui réalise diverses actions, parmi lesquelles : 1. Une tentative est faite pour recevoir un message m d une machine acceptée par le filtre recvfrom i (cf. figure 3.4). Si m est de type Arc(n,l,s), cela dénote une transition (s,a,s), où n est le numéro n j (s ) de l état source s assigné par la machine émettrice d index j = n mod N, et où l est le numéro défini par le processus superviseur pour le label a selon le protocole de cohérence des labels. Dans ce cas, le contenu du message m est utilisé pour mettre à jour les ensembles V i,t i et S i. Si m est de type Rec(k) ou Snd(k) (cf. 3.5), où k est le nombre total de messages respectivement reçus ou envoyés, cela dénote les différentes vagues de messages nécessaires à la détection de la terminaison. Si m est égal à End, la terminaison a effectivement été détectée et l algorithme sur la machine locale doit s arrêter. Les deux types de messages Lab(a) et Emg ne sont envoyés que par le processus superviseur dans le cadre respectif de la représentation canonique de labels et de l arrêt d urgence. Dans cet algorithme nous donnons clairement la priorité aux communications afin de privilégier le rassemblement d informations localement à une machine avant d effectuer des calculs locaux de construction de graphe. 2. Si aucun message n a pu être reçu, un état s V i est exploré (G) en énumérant une de ses transitions successeurs (s,a,s ) succ(s). Si le label découvert a est nouveau pour la machine i, alors l activité de représentation canonique de ce label est démarrée (C). Elle consiste par l envoi du label au processus superviseur (cf. partie C sur la figure 61), et par l attente de la réception du message du numéro unique lui correspondant (cf. C fig. 60). Une fois le label a connu, on test l état cible s de la transition (s,a,s ), pour savoir s il appartient à la machine i, c est-à-dire si h(s ) = i. Dans ce cas, la transition est écrite dans le fichier Bcg local, après avoir calculé un numéro approprié pour l état cible. Dans le but d obtenir une numérotation bijective des états du Ste sur l ensemble des N fichiers Bcg, chaque état s exploré par la machine i se voit assigner un numéro n i (s), de telle sorte que n i (s) mod N = i. Ceci est établit en utilisant un compteur c i, qui est initialisé à i et incrémenté de N chaque fois qu un nouvel état est visité. Si l état cible n appartient pas à la machine i, la transition est alors envoyée à la machine h(s ) sous forme de message Arc(n i (s),l,s ). On peut noter que les numéros n i (s) et l sont envoyés et non pas les contenus de l état s ou du label a. L état s également, consiste en un tuple de valeurs rendues canoniques selon le même protocole que pour

64 64 Chapitre 3. Les algorithmes Distributor et Coordinator les labels, mais à un niveau plus bas dans l algorithme. La machine h(s ) sera chargée d explorer l état s et d écrire la transition sur son fichier Bcg local, lequel contiendra toutes les transitions du Ste dont les états cibles sont explorés sur cette machine. 3. Enfin, dans le cas où aucun message n a été reçu, et qu il ne reste plus aucun état à visiter localement, la machine peut participer au protocole de terminaison (cf. (T) fig. 62) que l on décrit un peu plus dans la section Ces trois grandes actions sont ponctuées de messages de supervision à envoyer au processus superviseur (cf. (M) fig. 62), et sont constamment sous la surveillance de pannes locales ou externes à la machine (cf. (E) fig. 59 et fig. 62), des protocoles qui seront également détaillés Détection de la terminaison Dans le but de détecter la terminaison de la génération parallèle du Ste nous utilisons un algorithme basé sur un anneau virtuel, inspiré de [Mat87]. D après la définition générale, la terminaison globale d un système distribué est atteinte lorsque tous les calculs locaux sont finis, c est-à-dire que chaque machine i n a plus d états restants à explorer, ni des transitions à écrire dans son fichier Bcg B i, et que tous les canaux de communication sont vides, ce qui signifie que toutes les transitions émises ont été reçues. Le principe de l algorithme de détection de terminaison utilisé dans Distributor est le suivant. Toutes les machines sont supposées être sur un anneau virtuel unidirectionnel qui connecte chaque machine i à la machine suivante (i + 1) mod N. Chaque fois que la machine initiator ne reçoit plus de message et a fini ses calculs locaux, elle vérifie si la terminaison globale a été atteinte en générant deux vagues de messages Rec(k) et Snd(k) [Mat87] sur l anneau virtuel pour collecter le nombre de messages reçus et envoyés par toutes les machines. Chaque machine i compte les messages qu elle a reçu et envoyé en utilisant deux variables entières nbrecd i et nbsent i, et ajoute leurs valeurs aux nombres totalrecd i et totalsent i transportés par les messages Rec et Snd (cf. (T) fig. 62). Sur réception du message Snd(k) terminant la seconde vague, la machine initiator vérifie que le nombre total de messages reçus, totalrecd i, dans la première vague est égal au nombre total de messages envoyés, totalsent i, égale à k dans la seconde vague. Si c est le cas, cette machine devra informer les autres machines que la terminaison a été atteinte en envoyant un message End sur l anneau. Sinon, l initiator conclut que la terminaison n a pas été atteinte et qu il devra généré une nouvelle détection de terminaison plus tard (cf. (T) fig. 59 et fig. 60). La variable termstatus i indique les différents états de la détection de terminaison. NRM indique un état où la machine n a pas à contribuer à la terminaison, mais doit seulement s occuper de ses réceptions de messages et de ses calculs locaux. REC signifie que la machine doit envoyer à la machine voisine sur l anneau son nombre de messages reçus localement ajouté à k du message Rec(k). SN D a un sens identique sauf qu il concerne les messages émis. EN D correspond à la détection de la terminaison et l envoi d informations finales au processus superviseur. Enfin, ST OP désigne l arrêt de la génération distribuée.

65 3.4. L algorithme Distributor 65 Dans notre algorithme, chaque machine propage la vague courante seulement lorsque ses calculs locaux sont finis et lorsqu elle ne reçoit plus de messages. En effet, la priorité de l algorithme est donné à la réception de messages, puis aux calculs locaux, et enfin à la terminaison. Ajouté à cela, bien que notre algorithme de terminaison puisse être démarré de manière concurrente par n importe quel processus sur l anneau, nous avons décidé de limiter le démarrage de la terminaison seulement au processus initiator. De plus, nous faisons toujours passer la machine d un état monitorstatus i égale à REC ou SND, à un état NRM, immédiatement après qu elle ait transmis le message sur l anneau, afin qu elle ne soit pas bloquée en attente de messages de terminaison uniquement. Toutes ces optimisations réunies réduisent fortement le surcoût causé par des vagues de terminaison sans succès. En effet, notre détection de la terminaison utilise globalement moins de messages qu une terminaison où les messages de terminaison sont transmis immédiatement de machine en machine sur l anneau Détection de pannes franches Le cas de la terminaison normale de la génération distribuée est traité dans le cadre du protocole distribué de détection de la terminaison énoncé précédemment. Dans cette partie, nous décrivons comment le cas de la terminaison anormale est pris en compte. Ce genre de terminaison survient, soit lorsqu un processus Distributor doit faire un arrêt inopiné par suite d un problème grave, tel que la pénurie de mémoire, ou l impossibilité d écrire dans le fichier Bcg qu il doit produire, soit lorsque l utilisateur décide d interrompre prématurément la génération distribuée. Cela a nécessité l ajout, dans l algorithme, d un protocole spécial entre le processus superviseur et les processus répartis sur les N machines afin de permettre l arrêt d urgence, tout en laissant le système dans un état cohérent, état correspondant principalement à la fermeture des sockets et des fichiers Bcg ouverts et à la terminaison des processus répartis encore actifs. Le problème des terminaisons anormales, appelé également problème d arrêts d urgence consiste en trois étapes : le nettoyage des structures manipulées par le processus générateur avant arrêt, l envoi d information au superviseur par le processus générateur avant de s arrêter (cf. (E) fig. 59 et fig. 62), et la diffusion par le superviseur à tous les autres générateurs de l ordre de s arrêter d urgence (cf. (E) p69 et 60), car la génération n a plus de sens sans la présence d un ou de plusieurs processeurs. Une deuxième approche était de détecter dynamiquement la panne d un fils. Une technique aurait été de tester l existence de la socket connectée avec le superviseur pour savoir si un fils est en panne ou non, seulement la socket reste active pendant un grand laps de temps après que le processus se soit arrêté. Cette solution de détection dynamique d arrêt inopiné de processus fils ne semble pas être la plus adaptée. Avoir des messages explicites de la part du processus fils pour informer le processus superviseur de son arrêt inopiné est donc préférable.

66 66 Chapitre 3. Les algorithmes Distributor et Coordinator Gestion des types de données dynamiques Le protocole de cohérence des labels est celui expliqué dans la section 3.3. Dans l algorithme, il est délimité par la lettre C (cf. (C) fig. 60 et fig. 61). Une variable canonicstatus i permet de connaître l état dans lequel est la machine i au cours du protocole de calcul de la représentation canonique. N RM indique qu aucune canonisation de label n a été commencée, on peut alors traiter de nouvelles transitions (cf. (C) fig. 60). LAB signifie qu un nouveau label a été trouvé et qu il est nécessaire de la rendre canonique. La première étape est l émission de ce label au processus superviseur (cf. (C) fig. 61). REC représente la seconde étape qui est de récupérer le numéro unique du label en question (cf. (C) fig. 60). Enfin, une fois les informations concernant le label réunies, l état END permet le traitement de la nouvelle transition (cf. (C) fig. 61), à savoir le stockage de l état cible dans l ensemble des états visités V i qui devront être ultérieurement explorés. Nous ne pouvons pas faire apparaître le protocole de cohérence des termes au niveau de l algorithme Distributor car il est appelé directement par le compilateur traitant les types de données dynamiques du langage de spécification. Pour Lotos, c est le compilateur Cæsar.adt qui est chargé de faire appel au protocole de cohérence des termes pour chacune des composantes dynamiques qu il rencontre Visualisation et analyse du système Afin de rendre possible la visualisation d information concernant le système globalement, chaque processus fils doit envoyer des messages dits de monitoring au processus superviseur qui se chargera de les transmettre au processus de visualisation, si l utilisateur en a fait la requête. Pour ce faire, dès qu une action a été effectuée dans la génération parallèle, la machine i responsable de cette action passe dans un état, représenté par la variable monitorstatus i, dans lequel elle réunit des informations locales particulières et les transmet au processus superviseur (cf. (M) fig. 62). ST AT S signifie qu une transition a été nouvellement traitée. Il faut alors indiquer au processus superviseur l état d avancement de la machine i par l envoi de statistiques sur le nombre de messages émis et reçus, la charge en mémoire des états et la charge du processeur. TRM indique que la machine i est inactive et donc prête pour la détection de la terminaison. EN D correspond au besoin d envoyer les dernières informations concernant le fichier Bcg créé localement, préalablement au passage dans le dernier état avant arrêt de la génération, ST OP qui concerne l envoi des dernières statistiques de la machine i au processus superviseur. 3.5 L algorithme Coordinator Comme énoncé précédemment, le processus superviseur a une très grande utilité lors de la génération répartie du système de transitions étiquetées, en particulier celle d un gestionnaire. Parmi les raisons principales de son introduction vient le besoin d avoir un processus utilisateur dont le rôle serait de maîtriser la génération parallèle de l espace d états en perme-

67 3.5. L algorithme Coordinator 67 ttant le lancement et l arrêt des processus générateurs du graphe, ainsi que l interface entre l outil Distributor et l outil Bcg Merge à la fin de la génération. Ensuite, il est apparu comme étant le meilleur candidat pour recueillir des informations sur le système et permettre un suivi visuel par l utilisateur de l évolution de la génération distribuée, par le biais de statistiques et d informations sur la charge des processus. Enfin, il représente la solution la plus élégante pour la cohérence des termes contenant des types de données dynamiques et des labels de taille variable. Le comportement du processus superviseur est spécifié dans l algorithme Coordinator (cf. fig 3.8 et 3.9). Par la suite, nous allons présenter, pour chacun des protocoles énoncés précédemment, son rôle précis en relation avec les processus fils Distributor Détection de pannes franches et d arrêts par l utilisateur Le superviseur a un rôle très important du côté de la détection des comportements anormaux des processus qu il a créés. Il contrôle les messages d erreurs renvoyés par les processus de génération, concernant des débordements possibles de tables d états, de fichiers, de tables de termes ou de labels, ou des problèmes de communication par les sockets, et plus généralement toutes les erreurs que peuvent renvoyer les appels systèmes. Une fois l erreur détectée par le superviseur, celui-ci se charge de diffuser des messages d arrêt d urgence à tous les processus fils. La variable termstatus permet de modéliser l état de terminaison dans lequel le processus superviseur est. N RM traduit le fait que le processus superviseur n a pas commencer de protocole de terminaison particulier. Il est soit en train de rendre canoniques des labels (cf. (C) fig. 68 et fig. 69), soit en train de traiter des messages de monitoring avec le monitor M distant (cf. (M) fig. 68 et fig. 69). EMG indique qu une erreur a été détectée soit par un fils (cf. (E) fig. 69), soit localement par le superviseur (cf. (E) fig. 68 et fig. 69). Ce dernier devra alors démarrer le protocole d arrêt d urgence décrit par E dans l algorithme Coordinator en bas de la figure 3.9. Son autre fonctionnalité est de détecter les demandes d arrêts de la génération effectuées par l utilisateur par le biais du système de visualisation et de monitoring. Nous n avons pas représenté cette possibilité d arrêt dans l algorithme par soucis de clarté. Les conséquences de cette détection sont identiques à celles de la détection de pannes localement au processus superviseur, à savoir, le superviseur diffuse à tous les processus générateurs l ordre de s arrêter d urgence en envoyant un message Emg par les canaux de communication superviseur-générateurs Gestion des types de donnée dynamiques Nous avons vu que le rôle du superviseur dans la cohérence des termes et des labels était de réguler et d ordonnancer l insertion des termes ou labels dans les tables des fils. Le protocole pour le calcul de la forme canonique des labels implémenté par le superviseur est donc

68 68 Chapitre 3. Les algorithmes Distributor et Coordinator procedure Coordinator (in N, monitor; out initiator, R i, M) is A := ; termstatus := Nrm; M := ; canonicstatus := Nrm; nbended := 0; Any := {0.. N 1} while termstatus Stop do if termstatus Emg then if canonicstatus = Nrm then (M) if Receive (Any, m, sender) then case m is Lab(a) if a A then if monitor then (C) Stats(d) Stop(d) if InternalError(M) then termstatus := Emg; receiver := 0 else M := M {a} endif endif A := A {a}; canonicstatus := Can; receiver := 0 endif if InternalError(M) then termstatus := Emg; receiver := 0 else M := M {d} endif if InternalError(M) then termstatus := Emg; receiver := 0 else M := M {d} endif R i := nbvisit(d); nbended := nbended + 1 if nbended = N then termstatus := Stop endif Figure 3.8: Supervision de la génération parallèle d un système de transitions étiquetées: réception des messages (M) de monitoring, canonisation des labels (C), arrêt d urgence (E), et terminaison normale (S) (S) (E) (E) (E)

69 3.5. L algorithme Coordinator 69 (M) Trm endcase endif if InternalError(M) then termstatus := Emg; receiver := 0 else M := M {sender} endif Init initiator := sender Visit(d) R i := nbvisit(d); nbended := nbended + 1 else if receiver N then (C) (C) else if nbended = N then termstatus := Stop endif (S) Emg termstatus := Emg; receiver := 0 (E) if Send (receiver, Lab(a)) then receiver := receiver + 1 endif canonicstatus := Nrm endif endif else if receiver N then (E) (S) else endif endif endwhile if (receiver sender) (Send (receiver, Emg)) then receiver := receiver + 1 endif termstatus := Stop Figure 3.9: Supervision de la génération parallèle d un système de transitions étiquetées: canonisation des labels (C), arrêt d urgence (E), et terminaison normale (S) (E)

70 70 Chapitre 3. Les algorithmes Distributor et Coordinator exprimable simplement en deux parties. La première est la réception de nouveaux labels (Lab(a)) envoyés par les fils, et l ajout du nouveau label dans sa table de label locale (A i := A i {a}) (cf. (C) fig. 68). Ensuite, une seconde étape consiste à diffuser le nouveau label à tous les fils en même temps. Cela correspond au passage de la variable d état canonicstatus de NRM à CAN, et au protocole mis en place sur la figure 3.9 au niveau de la lettre C. Une fois le label émis à tous les processus fils, le processus Coordinator revient dans l état normal NRM pour le traitement des messages de monitoring ou pour d autres labels à rendre canoniques Visualisation et analyse du système Un protocole de visualisation et d analyse du système a été mis en place dans nos algorithmes Distributor et Coordinator pour offrir à l utilisateur la possibilité de suivre en tempsréel la progression de la génération distribuée. L outil comporte désormais une interface graphique en Tcl/Tk qui permet de visualiser en temps-réel diverses informations statistiques sur la construction du graphe : nombre d états visités et explorés, sur chaque machine et globalement, ensemble des étiquettes rencontrées, répartition des états entre les différentes machines, consommation mémoire, taux d utilisation des processeurs, etc. Ces statistiques sont calculées localement sur chaque machine, puis transmises au processus superviseur qui les centralise et les affiche sur l interface graphique. Cet outil de supervision de la génération distribuée de l espace d états permet de visualiser des informations systèmes (charge, mémoire disponible, trafic réseau...) sur tous les nœuds impliqués dans la génération parallèle. Il est composé d un outil de collecte locale d information, présent dans le processus superviseur grâce à la réception des messages de monitoring dans la partie (M) de l algorithme et grâce à la variable M permettant de stocker les informations, et d un outil pour véhiculer les informations sur le réseau, en l occurrence les canaux de communication dédiés entre le superviseur et les fils. L outil de visualisation a, quant à lui, fait l objet d un autre algorithme non modélisé dans le processus superviseur. Cet outil de visualisation permet d accéder à l information pertinente dans de gros volumes d information stockés dans la variable M du processus superviseur, et peut traiter des informations en provenance de sources variées, telles que des sources systèmes, applicatives, ou réseau. Ce chapitre a décrit nos avancées théoriques concernant la génération parallèle d espace d états en situant notre approche par rapport aux méthodes développées dans la littérature. Cette comparaison s est effectuée sur des composants fondamentaux présents dans toutes les techniques de construction répartie de graphe d accessibilité. La description de notre approche s est conclue par la présentation de deux algorithmes que nous avons développés pour permettre une génération performante et complète du système de transitions étiquetées modélisant le système à analyser. Seulement, on ne saurait prétendre que nos algorithmes sont exacts en ne se basant que sur une méthodologie rigoureuse et argumentée de chacun des composants utilisés dans nos algorithmes et sur de fortes convictions personnelles. Il est alors nécessaire de justifier et de vérifier la correction de notre méthode de manière formelle.

71 Chapitre 4 Vérification formelle de Distributor et de Coordinator Pour valider le processus de génération distribuée d espace d états que nous avons décrit dans le chapitre précédent, il serait nécessaire de valider chacun des protocoles de notre méthode (cf. sections 3.4 et 3.5) lorsqu ils sont entrelacés les uns avec les autres. Afin de valider les algorithmes Distributor et Coordinator décrits dans le chapitre 3, ce chapitre se propose de les spécifier formellement dans le langage Lotos et de vérifier des propriétés de bon fonctionnement sur les specifications obtenues à l aide de la boîte à outil Cadp. Dans la section 4.1, nous décrivons le langage Lotos qui sera notre support de description formelle des systèmes. Ensuite, les sections 4.2 et 4.3 décrivent respectivement deux versions du protocole, une simplifiée, comportant uniquement des processus de génération, et une plus complexe comportant le processus superviseur. Ces sections énoncent également les résultats engendrés par la vérification de propriétés temporelles et d équivalence dans chacune d elles. Finalement, après interprétation des résultats de ces vérifications, nous pourrons conclure quant à la satisfaisabilité de notre approche algorithmique. La spécification Lotos complète, ainsi que les propriétés vérifiées, sont données en annexe B. 4.1 Le langage Lotos Nous avons choisi le langage Lotos pour spécifier formellement nos algorithmes car il est adapté aux processus communiquants, tels que sont nos algorithmes Distributor et Coordinator. Dans cette section, nous nous proposons de rappeler brièvement les caractéristiques du langage Lotos, et d introduire un exemple de protocole modélisé en Lotos, protocole qui sera par la suite réutilisé comme donnée d entrée pour la vérification de nos algorithmes. 71

72 72 Chapitre 4. Vérification formelle de Distributor et de Coordinator Sémantique du langage Historiquement, Lotos a été défini pour permettre la description des services et des protocoles de télécommunications, en particulier les systèmes OSI 2. Conçu entre 1980 et 1988, il est défini par la norme ISO 8807 (définition formelle : [ISO89], présentation générale : [BB88]). Lotos est une technique de description formelle qui se décompose en deux parties distinctes : la partie contrôle et la partie données. La description du contrôle s inspire des algèbres de processus, notamment CCS (Calculus of Communicating Systems) [Mil80] et TCSP (Theory of Communicating Sequential Processes) [Hoa85] : le comportement des programmes est décrit par des expressions algébriques. La synchronisation et la communication s effectuent exclusivement par rendez-vous, sans partage de mémoire. Une présentation de cette partie est faite dans l annexe B de [Gar89]. La description des données est faite par des types abstraits algébriques, en s inspirant largement du langage ActOne [EM85]. Un type comprend des domaines de valeurs, des opérations sur ces valeurs et des équations qui définissent la sémantique de ces opérations. De nouveaux types peuvent être créés à partir de types existants par enrichissement, renommage, paramétrisation, etc Un exemple : le protocole d exclusion mutuelle Nous allons utiliser tout au long de ce chapitre un exemple du protocole d exclusion mutuelle qui sera notre fil conducteur dans les sections qui vont suivre, où il sera utilisé comme un exemple d espace d états que devront générer nos algorithmes spécifiés formellement. Pour situer l exclusion mutuelle dans son contexte, nous pouvons dire qu elle est issue de la concurrence de processus lors de l accès à des ressources partagées, pouvant provoquer l incohérence de celles-ci. Gérer la concurrence revient à contrôler que des accès concurrents s exécutent de manière cohérente. La manière la plus simple de parvenir à cette cohérence consiste à garantir que pour chaque ressource au plus une section de code qui la manipule soit en cours d exécution. Une telle section de code est appelée section critique. Bien que d autres manières de gérer la concurrence soient possibles, comme la séquentialisation des transactions, nous n utiliserons dans ce chapitre que la technique de l exclusion mutuelle entre sections critiques. Nous n illustrerons pas l intérêt des sections critiques dans notre exemple, seulement le mécanisme de prise et de relâche du verrou, appelé également sémaphore, par des processus. Nous avons modélisé en Lotos le protocole d exclusion mutuelle entre deux processus tentant d accéder à une section critique. La spécification en Lotos correspondante est présente dans la figure 4.1. Elle est constituée de deux types de processus, un modélisant le sémaphore Sem et l autre représentant un processeur Proc. Le comportement spécifié est la mise en parallèle de deux processeurs P roc synchronisés sur les actions possibles au niveau du sémaphore Sem, comme 2 Open Systems Interconnection

73 4.1. Le langage Lotos 73 specification MUTEX [REQ1, REL1, REQ2, REL2, CS1, NCS1, CS2, NCS2] : noexit behaviour ( Proc [NCS1, CS1, REQ1, REL1] Proc [NCS2, CS2, REQ2, REL2] ) [REQ1, REL1, REQ2, REL2] Sem [REQ1, REL1, REQ2, REL2] where process Proc [NCS, CS, REQ, REL] : noexit := NCS; REQ; CS; REL; Proc [NCS, CS, REQ, REL] endproc process Sem [REQ1, REL1, REQ2, REL2] : noexit := REQ1; REL1; Sem [REQ1, REL1, REQ2, REL2] [] REQ2; REL2; Sem [REQ1, REL1, REQ2, REL2] endproc endspec Figure 4.1: Protocole d exclusion mutuelle en Lotos entre deux processus

74 74 Chapitre 4. Vérification formelle de Distributor et de Coordinator la prise du verrou par REQ ou la relâche du verrou par REL. La spécification de Sem indique que la prise du sémaphore, représentée par l action REQ1 faite par le processeur 1 par exemple, est obligatoirement suivie d une relâche du verrou par le même processeur, dans notre cas par REL1. La condition modélisée est même plus forte, puisqu aucun autre processeur ne peut prendre le verrou si un autre processeur l a pris avant, et ne peut pas non plus prendre le verrou si le verrou n a pas été relâché par le processeur le retenant. Une fois cette spécification, du protocole d exclusion mutuelle entre deux processus, établie, il est possible de générer chacune des transitions possibles de l espace d états du système, et chacune des actions que peuvent faire les processus à partir d un instant initial où les deux processus sont dans une section non-critique. En l occurrence, N CS1 et N CS2 correspondent respectivement au passage du processus 1 ou 2 de la zone de code non critique au début de la zone critique. Les actions REQ1 et REQ2 traduisent la prise du verrou. CS1 et CS2 représentent, quant à elles, l accès à la section critique. Enfin, REL1 et REL2 signifient que le processus 1 ou le processus 2 relâchent le verrou qu ils avaient pris au préalable. La figure 4.2 dépeint l ensemble des états résultants de notre modélisation du protocole de mutuelle exclusion entre deux processus 1 et 2. Cet ensemble a 12 états et 20 transitions NCS2 CS1 CS2 NCS REL2 CS1 NCS2 REQ1 REQ2 NCS1 CS2 REL REL1 REQ1 NCS2 NCS1 REQ2 REL2 1 2 NCS1 0 NCS2 Figure 4.2: Modèle Ste d un protocole d exclusion mutuelle Nous ne vérifierons aucune propriété sur ce Ste, pour montrer qu il représente bien une exclusion mutuelle, car la vérification serait sans grand intérêt dans le présent travail. On peut néanmoins vérifier par une simple lecture du graphe que les deux propriétés caractéristiques de l exclusion mutuelle sont garanties, c est-à-dire que : A tout instant, au plus un processus est en cours d exécution d une section critique. L action CS1 (respectivement CS2) est obligatoirement encadré par les transitions REQ1 et REL1 (respectivement REQ2 et REL2). Une autre façon de le dire est que CS1 ne peut être suivi par CS2 que si REL1 et REQ2 sont présents dans les relations les séparant, et vis et versa. Ce type de propriété correspond à une propriété de sûreté.

75 4.2. L algorithme Distributor simplifié 75 Tout processus demandant à exécuter une section critique, par exemple lors d un appel à N CS1, pourra l exécuter au bout d un temps fini, comme lors du retour de REL2. Sur le graphe 4.2, cette propriété est représentée par le fait que des transitions vont directement de la fin d une section critique avec le relâchement du verrou, REL1 ou REL2, au début de la section critique du processus opposé si celui-ci attendait le sémaphore, c est-à-dire s il avait exécuté l action N CS2 ou N CS1. Il s agit par exemple de la transition entre l état 11 et l état L algorithme Distributor simplifié Dans le chapitre 3 précédent, nous avons apporté une description précise de l algorithme Distributor utilisé par les processus fils lors de la génération distribuée de l espace d états. Nous avons vu que cinq protocoles y avait été intégrés. Nous avons également distingué deux protocoles qui ne faisaient pas intervenir le processus superviseur. Il s agit du protocole de construction répartie du système de transitions et du protocole de détection distribuée de la terminaison. Par version simplifiée de l algorithme Distributor, nous entendons sa restriction à ces deux seuls protocoles pour ne pas avoir besoin d utiliser l algorithme Coordinator représentant le processus superviseur, afin d obtenir un système plus simple dans le cadre d une première vérification formelle Spécification en Lotos Nous avons spécifié formellement l algorithme simplifié de Distributor en séparant dans deux processus distincts la génération distribuée du graphe d accessibilité et les mécanismes de fonctionnement de la communication. Cette séparation nous est apparue nécessaire car elle modélise bien les problèmes liés à la communication par sockets non-bloquantes entre les processus de la génération. La figure 4.3 suivante représente les différents processus Lotos mis en œuvre. SEND RECV SEND RECV socket01 socket12 Distributor(0) Distributor(1) Distributor(2) socket10 socket21 RECV SEND RECV SEND SEND RECV socket02 socket20 RECV SEND Figure 4.3: Architecture de la spécification LOTOS pour 3 processus de génération Dans notre spécification, seulement trois machines ont été modélisées pour générer de manière distribuée l espace d états. Chacune de ces machines exécutent une instance de

76 76 Chapitre 4. Vérification formelle de Distributor et de Coordinator la spécification en Lotos du protocole de construction répartie du système de transition et du protocole de détection distribuée de la terminaison. Entre elles se trouvent des sockets dédiés à l émission et réciproquement à la réception de messages. Chacune de ces sockets exécute une instance de la modélisation Lotos du processus de communication. Leurs caractéristiques sont de reposer sur des canaux de communication fiables et FIFO, et d avoir des tampons de capacité infinie de messages. Leur rôle est de représenter l intéraction présente dans les actions de l algorithme Distributor avec les sockets Tcp/Ip qui peuvent être vides ou avoir des messages en attente de traitement. Pour une description complète de nos spécifications en Lotos des différentes parties de l algorithme simplifié de Distributor nous vous reportons à l annexe B.2. Une fois cette spécification établie, il est possible de simuler notre algorithme formel en lui donnant un espace d états à générer de manière distribuée. C est ici qu intervient notre exemple de l exclusion mutuelle, puisqu en décrivant en Lotos les différentes transitions et actions de son graphe d états (cf. fig 4.2), nous pouvons l utiliser comme une donnée d entrée à notre algorithme Distributor. Ce dernier se comportera comme s il ne connaissait que l état initial du graphe d états du protocole de l exclusion mutuelle, ainsi que la fonction successeur lui permettant de calculer les successeurs d un état du graphe. La description Lotos complète du graphe d états du protocole d exclusion mutuelle entre deux processeurs et de la partie données utilisée par l algorithme formalisé Distributor, est présente en annexe B.1. Il est alors intéressant de générer, à son tour, l espace global des états de notre protocole Distributor simplifié, pour obtenir un Ste modélisant le comportement de notre algorithme. La figure 4.4 désigne cet espace d états, réduit modulo la bisimulation de branchement, dans le cadre d une génération distribuée, avec deux machines, du graphe d accessibilité du protocole d exclusion mutuelle entre deux processeurs. Nous ne présentons pas les graphes d états de l algorithme Distributor pour un ensemble de trois ou plus machines par soucis de lisibilité et de compréhension des graphes obtenus. Le système de transitions étiquetées résultant contient 59 états et 94 transitions, sur lesquelles les étiquettes ont été renommées pour être plus lisibles, et représente un support idéal pour vérifier des propriétés logiques sur notre génération distribuée Vérification de propriétés en logique temporelle Une propriété modélise un comportement particulier que doit vérifier un système. Le besoin de définir des propriétés d un système peut se faire ressentir dans des situations telles que l analyse de bon fonctionnement, la recherche de causes de dysfonctionnement, l analyse de risques, l évaluation de performances, l expression des objectifs, la détermination des contraintes, et bien d autres encore. Une propriété d un modèle ou d un système est une qualité qui lui est propre. La définition de propriétés du système peut se faire par un langage de haut niveau tel que la langue française.

77 4.2. L algorithme Distributor simplifié T (10, REL1, 2) T (4, REQ2, 8) 25 T (4, REQ1, 7) T (6, NCS2, 10) T (9, REL2, 0) T (9, NCS1, 11) T (9, REL2, 0) T (4, REQ1, T 7) (11, REL2, 1) T (7, CS1, 10) T (1, NCS2, 4) T (4, REQ2, T 8) (1, REQ1, 3) T (5, CS2, 9) 29 T (11, REL2, 1) T (6, NCS2, 10) T (6, REL1, 0) T (3, CS1, 6) 7 T (4, REQ2, 8) T (10, REL1, 2) T (7, CS1, 10) T (9, REL2, 0) T (9, NCS1, 11) T (11, REL2, 1)T (4, REQ1, 7) T (1, NCS2, 4) T (7, CS1, 10) T (8, CS2, 11) 26 T (5, NCS1, 8) T (11, REL2, 1) T (9, NCS1, 11) T (1, NCS2, 4) T (10, REL1, 2) T (9, REL2, 0) T (5, CS2, 9) TRM (0) TRM (1) T (3, NCS2, 7) T (6, REL1, 0) T (6, NCS2, 10) 37 T (1, NCS2, 4) T (1, NCS2, 4) T (1, NCS2, 4) T (5, CS2, 9) 46 T (8, CS2, 11) T (9, NCS1, 11) 1 2 T (11, REL2, 1) T (1, NCS2, 4) T (4, REQ1, 7) T (1, REQ1, 3) T (1, REQ1, 3) T (1, REQ1, 3) T (3, NCS2, 7) T (11, REL2, 1) 11 9 T (3, CS1, 6) T (9, REL2, 0) T (6, NCS2, 10) T (11, REL2, 1) T (5, NCS1, 8) T (1, REQ1, 3) T (9, REL2, 0) T (10, REL1, 2) T (9, REL2, 0) T (4, REQ2, 8) T (2, REQ2, 5) T (2, NCS1, 4) T (0, NCS2, 2) T (0, NCS1, 1) T (3, CS1, 6) TRM (1) TRM (0) T (6, REL1, 0) T (3, NCS2, 7) T (3, NCS2, 7) T (11, REL2, 1) T (3, NCS2, 7) 28 T (6, NCS2, 10) 47 T (1, REQ1, 3) T (4, REQ2, 8) T (5, CS2, 9) T (1, REQ1, 3) T (8, CS2, 11) T (7, CS1, 10) T (4, REQ1, 7) T (1, REQ1, 3) T (9, NCS1, 11) T (5, NCS1, 8) T (10, REL1, 2) T (9, REL2, 0) T (3, CS1, 6) T (7, CS1, 10) T (11, REL2, 1) T (4, REQ2, 8) T (1, NCS2, 4) 59 états, 94 transitions Figure 4.4: Ste de la spécification Lotos avec deux processus de génération sur l exemple du protocole d exclusion mutuelle

78 78 Chapitre 4. Vérification formelle de Distributor et de Coordinator Seulement pour être analysable sur le modèle formel du système, il est nécessaire de l interpréter dans un langage approprié comme le µ-calcul modal, qui dispose d une syntaxe, d une sémantique, d une qualification et d une quantification précises. A la fin de la vérification, il ne reste plus qu à interpréter sur le système les résultats de la vérification des propriétés sur le modèle. Pour définir une propriété d un modèle, on établit tout d abord les caractéristiques des entités du modèle, puis les interactions entre les entités et/ou avec l environnement, et enfin les relations et dépendances avec les autres propriétés du même modèle. Les deux classes de propriétés les plus utiles sont : les propriétés de vivacité et les propriétés de sûreté. Une propriété de vivacité traduit le fait que quelque chose de bien finira par arriver. Une propriété de sûreté traduit le fait que quelque chose de mauvais ne doit pas se produire et n arrivera donc jamais. Un exemple de propriété que l on souhaiterait vérifier en premier lieu, est le fait que l algorithme Distributor génére effectivement le graphe entier des états du protocole de mutuelle exclusion. Une méthode permettant de prouver que tout le graphe a été traité est d imprimer les transitions rencontrées lors de l exploration/génération de l espace d états. Pour ce faire, on crée une porte de rendez-vous appelée Print au sein de la spécification LOTOS, et dès qu une transition est découverte, on l émet sur cette porte. Cette propriété, et bien d autres, font partie des propriétés dites de sûreté définies dans la partie qui suit. Nous avons spécifié chacune des propriétés de sûreté et de vivacité en µ-calcul modal. Ces propriétés sont données en annexe B.3. Quatre propriétés de sûreté ont été vérifiées sur notre algorithme au moyen de l outil Evaluator 3.0 [MS00] : Toutes les séquences d exécution de transitions dans le graphe d états de Distributor sont finies, ce qui équivaut à dire que le comportement de la génération distribuée se termine toujours. Sur chaque séquence de transitions menant à un état de blocage, appelé également deadlock, il doit y avoir une action d impression pour chacune des transitions du Ste donné en paramètre d entrée de l algorithme Distributor. Ainsi, dans le cas du protocole de l exclusion mutuelle, chaque séquence doit avoir une longueur de 20 transitions avant un deadlock. Cette propriété prouve que l espace d états entier du protocole d exclusion mutuelle est généré par notre algorithme. Chaque état de blocage doit être précédé par une séquence d actions de terminaison, exactement une par processus dans le réseau. Sur le graphe 4.4, cette propriété peut se voir par les deux dernières actions réalisées au sommet du graphe d états. Cela montre bien que la terminaison est correctement détectée.

79 4.3. Extension de la spécification par l algorithme Coordinator 79 Aucune action n est possible après que toutes les actions de terminaison aient été exécutées. Une propriété de vivacité a été modélisée et vérifiée également avec succès sur l algorithme Distributor : Un état de blocage est finalement toujours atteint. Par la propriété de sûreté précédente, cet état de deadlock prouve que la terminaison normale de la génération est correctement effectuée par le protocole de détection distribuée de la terminaison. Ainsi, dans le cadre de la formalisation de l algorithme de génération distribuée de système de transition, restreint aux protocoles de construction répartie du graphe et de détection distribuée de la terminaison, nous avons vérifié que notre algorithme Distributor répondait à nos spécifications et qu il générait correctement l espace d états correspondant au modèle à analyser. Seulement, l algorithme actuel de Distributor fait intervenir beaucoup plus de protocoles ainsi que le processus superviseur Coordinator, impliquant un degré supplémentaire de complexité dans le processus global de génération parallèle de graphe. 4.3 Extension de la spécification par l algorithme Coordinator Cette section présente une extension de notre spécification Lotos précédente, en lui ajoutant le protocole de cohérence des labels en plus des protocoles de construction et de terminaison. Cet ajout implique en conséquence l introduction du processus superviseur Coordinator dans notre modélisation formelle du processus de génération distribuée de l espace d états Spécification en Lotos Par rapport à la première étude de cas, nous avons défini un nouveau processus reflétant le comportement de l algorithme Coordinator pour la gestion des labels. La figure 4.5 suivante illustre cette extension, et la place du processus superviseur par rapport à tous les processus de génération. Le superviseur est donc connecté directement à chacun des processus de génération par le même mécanisme de communication que précédemment, c està-dire par deux sockets, une pour l émission de messages et l autre pour la réception de messages, ayant les mêmes caractéristiques de fiabilité et les mêmes types de buffer. Pour une description complète des nouvelles spécifications Lotos modélisant cette étude de cas, nous vous référons à l annexe B Vérification de propriétés d équivalence En plus des propriétés usuelles énoncées dans la sous-section 4.2.2, nous avons vérifié une propriété bien plus expressive concernant le graphe d états de notre extension de la spécification

80 80 Chapitre 4. Vérification formelle de Distributor et de Coordinator RECV SEND Coordinator(3) SEND RECV RECV SEND socket03 socket30 socket13 socket31 socket23 socket32 SEND RECV SEND RECV SEND RECV SEND RECV SEND RECV socket01 socket12 Distributor(0) Distributor(1) Distributor(2) socket10 socket21 RECV SEND RECV SEND SEND RECV socket02 socket20 RECV SEND Figure 4.5: Architecture de la spécification LOTOS pour 3 processus de génération formelle de Distributor. Il s agit de relation d équivalence par branchement, ou branching equivalence, entre graphes. Cette relation permet d indiquer si le comportement des deux graphes est semblable par une technique de bisimulation. Dans notre cas, l équivalence est totale entre le graphe obtenu dans cette section, avec tous les ajouts nécessaires à la représentation canonique des labels, et le graphe plus simple de la section précédente. Les deux graphes d états obtenus après minimisation modulo la bisimulation de branchement, sont identiques à l état près. Nous pouvons en conclure que notre protocole de cohérence des labels est complètement transparent au niveau de la génération distribuée par chacune des machines et qu il contribue avec succès à la génération parallèle globale de l espace d états du modèle analysé. Pour conclure ce chapitre, nous pouvons dire que ces phases de vérifications formelles de nos algorithmes étaient nécessaires pour justifier la correction par rapport au comportement souhaité de tels algorithmes dans le cadre de la génération parallèle d espace d états. Elles constituent un argument de poids pour la validation de notre approche et des différents choix algorithmiques qui ont été faits pour aboutir aux algorithmes Distributor et Coordinator. Cependant une dernière étape subsiste encore pour finaliser notre travail, celle de l implémentation de ces algorithmes et de leur expérimentation sur des cas concrets de systèmes complexes à analyser.

81 Chapitre 5 Réalisation et expérimentation Ce chapitre se propose de refléter la partie appliquée de notre travail qui se partage en deux étapes : l implémentation dans l outil Distributor des nouveaux algorithmes proposés, et notamment celui de la gestion des données dynamiques, et l expérimentation du nouvel outil obtenu, sur des applications complexes, comme celles contenues dans la base de démonstrations de la boîte à outils Cadp ou issues des contrats industriels du projet Vasy, et sur des configurations pouvant aller jusqu à 220 machines. L objectif de la première étape était également d attacher un soin particulier à la conception modulaire de l outil, afin que certains modules puissent être réutilisés. Par exemple, les primitives de communication ont été regroupées dans une bibliothèque générique qui peut servir ultérieurement à la parallélisation d autres outils de vérification de Cadp. Un des buts principaux de l étape d expérimentation était de pouvoir générer des modèles ayant une taille de l ordre du Giga d états à l aide de la grappe de 220 Pc du projet Apache à l Inria. Dans la section 5.1 suivante, nous présentons l environnement Open/Cæsar dans lequel s inscrit directement notre outil de génération distribuée d espace d états. La section 5.2 focalisera nos réalisations sur les primitives génériques et efficaces de communication utilisées pour la transmission de différents types de messages entre les machines. Enfin, la section 5.3 décrira les différentes expériences menées à la fois sur un réseau de stations de travail sous Solaris, et sur une grappe de Pc sous Linux. 5.1 L environnement Open/Cæsar L environnement générique Open/Cæsar [Gar98] est un composant essentiel de la boîte à outils Cadp. Il fournit une représentation implicite des modèles Ste, qui permet l exploration à la volée d un système de transitions étiquetées sans l avoir préalablement construit, mais en le générant dynamiquement au fur et à mesure des besoins. Concrètement, cette représentation est faite au moyen d une interface de programmation en langage C, comportant une description des états du système de transitions étiquetées, ainsi que des fonctions 81

82 82 Chapitre 5. Réalisation et expérimentation pour accéder à l état initial et pour énumérer les successeurs d un état donné. Cette interface est munie de plusieurs bibliothèques (tables de hachage pour les états, listes de transitions, piles, etc.) destinées à faciliter la programmation d algorithmes d exploration des système de transitions étiquetées et de vérification à la volée. L architecture de l environnement Open/Cæsar est illustrée dans la figure 5.1. On distingue trois types de composantes : les compilateurs, qui traduisent les langages d entrée vers l interface Open/Cæsar (un exemple est le compilateur Cæsar pour Lotos) ; l interface Open/Cæsar elle-même, équipée des bibliothèques d exploration de système de transitions étiquetées ; les outils de vérification à la volée, qui utilisent les primitives de l interface Open/Cæsar pour mettre en œuvre les algorithmes de vérification (un exemple est le model-checker Evaluator 3.0). programme Environnement Open/Cæsar propriété compilateur module graphe outil de vérification bibliothèques compilateur C exécutable résultats Figure 5.1: L environnement Open/Cæsar L interface Open/Cæsar permet de séparer les aspects liés au langages d entrée, car pris en charge par les compilateurs, des aspects liés à l analyse des modèles de système de transitions étiquetées, car pris en charge par les outils de vérification. De cette manière, tous les outils de vérification à la volée développés avec Open/Cæsar sont génériques, pouvant être appliqués à n importe quel langage qui dispose d un compilateur vers l interface Open/Cæsar. A l heure actuelle, il existe plusieurs langages connectés à Open/Cæsar : Lotos, réseaux d automates communicants, Sdl et Uml. Ces langages bénéficient donc naturellement des

83 5.2. Les primitives de communication 83 outils de simulation et de vérification à la volée disponibles dans Cadp : le simulateur graphique Ocis, l outil de recherche de séquences Exhibitor, l outil d exécution aléatoire Executor, le model-checker Evaluator 3.0, etc. Par souci de généralité, l outil Distributor a été également développé au moyen de l interface Open/Cæsar, ce qui lui confère un caractère indépendant vis-à-vis du langage d entrée. 5.2 Les primitives de communication Nos travaux théoriques ont abouti à un outil prototype très performant appelé Distributor V3.0 implémenté en ANSI C et utilisant les sockets pour les communication. Notre modèle de programmation étant basé sur le passage de messages, la communication joue un rôle très important. Les performances globales de notre système dépendent beaucoup du surcoût engendré par les communications Etude des limitations existantes Après une relecture et une compréhension totale du code de Distributor V2.0, consistant en plus de 6000 lignes de code C, une première réalisation a été de rendre l outil stable en enlevant et modifiant de nombreuses parties erronées qu il contenait. Une fois cette étape bien avancée, nous avons amélioré de manière significative la partie de communication qui entre en jeu dans la génération distribuée de l espace d états. Ces améliorations ont tout d abord consisté à définir une configuration efficace pour la communication inter-processus à base de sockets Tcp/Ip. Nous considérons l ensemble des processus impliqués dans la génération comme formant un graphe complètement interconnecté : n importe quel processus peut communiquer directement avec n importe quel autre processus. Puisque nous utilisons le protocole de communication Tcp/Ip, à tout instant, nous avons N (N 1) sockets établies pour N processus impliqués dans la génération. En ajoutant à cela le processus superviseur Coordinator directement connecté à chacun des processus générateurs, on obtient finalement la création de N 2 sockets globalement, et exactement N sockets sont nécessaires par processus. Il s agit là du nombre minimum de sockets nécessaire pour établir un graphe entièrement connecté de N + 1 processus. La version précédente de l outil Distributor, quant à elle, utilisait 2N 2 sockets, soit 2 fois trop d entités à gérer et à manipuler. Nous avons étudié différentes solutions pour réduire le nombre de sockets qui, nous le pensons, pourrait devenir une limitation future de l outil, notamment à cause d effets de bord liés à l incapacité du système à gérer, par exemple lors de l utilisation de primitives select, un nombre trop important de sockets. Une solution envisagée consisterait à dédier un processus pour la réception des messages venants de tous les autres processus et pour la réémission de ces messages aux processus cibles. Un tel processus n aurait pour fonction que d être un relais des messages émis. La complexité du nombre important de sockets à manipuler est remplacée par la complexité

84 84 Chapitre 5. Réalisation et expérimentation de la gestion par un seul processus de la transmission de tous les messages. Cette solution ne saurait être satisfaisante, car ce processus constituerait certainement un goulot d étranglement dans la génération de l espace d états. Cependant, elle présente un très grand avantage, puisqu elle diminue le nombre de sockets totales à 2N, répartis en une socket par processus générateur, et N sockets pour le processus distributeur de messages, processus pouvant également avoir le rôle du processus superviseur. Ce nombre de sockets étant linéaire en nombre de machines impliquées dans la génération, cette solution a le mérite d avoir de très bonnes propriétés pour le passage à l échelle. Une deuxième solution consisterait à utiliser non pas le protocole Tcp/Ip mais le protocole Udp/Ip qui donnerait le nombre minimal de sockets nécessaires, à savoir N sockets au total soit une socket à chacun des processus, mais déplacerait la complexité liée à un nombre trop élevée de sockets à celle de la sûreté d émission des messages. Un mécanisme d accusé de réception des messages devra alors être utilisé pour certifier de la réception de chacun des messages envoyés, ce qui revient à un grand surcoût en communication, rejetant également cette solution. Une conséquence de notre réduction globale du nombre de sockets, a entraîné une réduction importante du nombre de connexions nécessaires à la transmission des paramètres aux machines distantes par le processus superviseur, mais également lors de la transmission d états entre processus générant l espace d états. Ainsi, la phase d initialisation du processus est plus rapide et la communication dans son ensemble est accélérée durant la génération d espace d états Architecture nouvelle de communication Une autre amélioration primordiale à l outil est l établissement d une couche logicielle de primitives de communication permettant à l utilisateur de ne pas avoir à se soucier des détails et mécanismes des accès systèmes nécessaires à la transmission de messages par sockets. Ces primitives, génériques, peuvent aussi bien être utilisées dans le cadre de l outil Distributor, que dans tout outil basé sur une programmation par passage de messages. Des mécanismes simples de gestion optimisée de tampons logiques y sont intégrés et sont paramétrisables par l utilisateur pour répondre au mieux à ses besoins. Dans le cadre de Distributor, ils servent, par exemple, à regrouper des paquets d états avant de les envoyer au processus destinataire, au lieu de les envoyer un par un dès qu ils sont découverts. Ce système de mise en tampon logique de messages est très important pour réduire les coûts en communication. Concernant les messages eux-mêmes, leurs tailles avaient été fixées implicitement dans les versions précédentes de Distributor par des valeurs pas du tout adaptables et adaptées à la multitude des systèmes et formalismes existants et pouvant être analysés. Notre outil de communication est, en revanche, basé sur des messages de taille variable dont l entête contient toutes les informations nécessaires à l extraction du message. Deux mécanismes, un pour le paquetage et un pour le dépaquetage de messages, sont intégrés à notre interface de communication et sont invisibles de l utilisateur. L utilisateur n a pas à se soucier de l interprétation des flots d octets qu il reçoit sur ses sockets, elle est intégrée à cette couche

85 5.3. Expérimentations 85 de primitives de communication entre le système et le programme utilisateur. 5.3 Expérimentations Les outils Distributor V3.0 et Bcg Merge V2.0 ont été expérimentés dans deux types d environnements de calcul : d une part, le réseau local de l équipe Vasy composé de stations de travail fonctionnant sous Solaris ou Linux et connectées par un réseau Ethernet 100 Mbits, et d autre part, la grappe de Pc développée par les projets Sirac et Apache de l Inria. Les expériences ont concerné diverses applications de grande taille, comme une version statique du protocole Brp de Philips [Mat96], le protocole du Bit Alterné présent dans le système Osi, et le protocole d arbitrage du bus Scsi-2 [ANS94] avec des configurations de 5 et 6 disques. Les premiers résultats montrent la possibilité de générer des graphes de grande taille, autour de 15 millions d états, avec des gains de vitesse, ou speed up, importants par rapport à la version séquentielle de génération d espace d états présente dans l outil Generator. Les résultats indiquent également que la fonction de hachage choisie assure un bon équilibrage de charge La grappe de Pc de l Inria Les performances des ordinateurs de bureau standards à base de processeur Intel ont atteint un tel niveau qu il est aujourd hui possible de construire à partir de ces machines des supercalculateurs aussi rapides que les calculateurs dédiés type Cray, Ibm Sp ou Sgi Origin D autre part, des problèmes technologiques ou simplement les coûts de certains composants, comme les commutateurs pour l accès à la mémoire par exemple, limitent les possibilités de passage à l échelle des machines multiprocesseurs (Smp). Dans ce contexte, les grappes de Pc apparaissent comme une très bonne alternative aux autres moyens de calculs. C est pourquoi nous avons souhaité repousser les limites de la génération parallèle d espace d états en exploitant au mieux les possibilités des machines parallèles de type Mimd à mémoire distribuée, telles que les grappes de Pc ou les réseaux de station de travail, présentes dans les laboratoires de recherche et dans les entreprises. Nous considérerons ici (cf. fig 5.2), une architecture de grappe banalisée, aussi appelée grappe Beowulf 3. Elle est composée de 225 Pc monoprocesseurs dédiés aux calculs hautes performances, reliés par un réseau Ethernet lui aussi dédié, mixant des vitesses allant de 100 mégabits/s sur l interface réseau des machines à 1 gigabit/s sur les interfaces des commutateurs. Cette grappe est constituée de 220 machines (ou nœuds) sous Linux mdk ou Linux Chaque nœud est un Pc Hp e-vectra équipé d un processeur Pentium III de 256 Mo de mémoire, 15 gigas de disque et d un port réseau Fast Ethernet. Les 220 machines sont 3 Grappe générique dont les composants matériels et logiciels sont des standards de l industrie et les environnements non propriétaires.

86 86 Chapitre 5. Réalisation et expérimentation connectées à un réseau Ethernet matérialisé par 5 Hp procurve 4000 commutateurs reliés entre eux par des liens en Gigabit. Figure 5.2: La grappe de 220 Pc de l Inria Notre outil est indépendant du type de système de fichiers utilisé sur la grappe. Cependant, un certain inconvénient peut être noté sous Nfs, lorsque les répertoires de travail répartis sont centralisés et pointent vers un même et unique répertoire, nous obligeant à donner des noms de fichiers Bcg différents pour chaque machine qui génére une partie du graphe d états distribué sous ce format Bcg. De plus, par soucis de portabilité, nous n utilisons pas de primitives systèmes particulières à un système de fichier comme Nfsp, présent sur la grappe de Pc de l Inria Analyses de performances Nos travaux ont consisté à augmenter les performances, la robustesse et l ergonomie de l outil et de permettre le passage à l échelle sur un nombre très important de machines. Les nouveaux outils Distributor V3.0 et Bcg Merge V2.0 ont été expérimentés sur la grappe de 225 Pc du projet Apache sur des configurations allant jusqu à 70 machines. Les résultats observés confirment les résultats précédemment obtenus dans Distributor V1.0 et Bcg Merge V1.0 sur des configurations plus réduites, à savoir une accélération importante et un bon équilibrage de charge entre les machines.

87 5.3. Expérimentations 87 Speedup La mesure d accélération qui peut être faite sur un outil parallèle est celle qui reflète le gain en temps par rapport à une version séquentielle. Mathématiquement, on peut traduire le speedup selon la formule suivante : S(N) = T seq /T par S(N) est le speedup du système parallèle utilisant N machines, et T seq et T par sont respectivement les temps d exécution avec une approche séquentielle ou avec une approche parallèle sur un exemple donné. Nous avons effectué une génération de l espace d états pour les trois protocoles : Bit Alterné, Brp et Scsi-2. Pour chacun d eux, nous avons utilisé différentes configurations de machines pour évaluer l accélération qu apportait notre solution parallèle par rapport à l outil Generator de génération séquentielle de système de transitions présent dans la boîte à outil Cadp. La figure 5.3 illustre l accélération que permet notre solution parallèle selon le nombre de machines utilisées. Il est intéressant de noter que de manière générale, l accélération observée est proche d être linéaire en nombre de machines, ce qui confère de très bonnes propriétés de parallélisme de notre approche. On peut également constater que l accélération optimale pour le protocole Brp est obtenue avec une configuration comportant 10 machines. Le surcoût engendré en utilisant plus de machines est tel que le système dépense plus de temps à communiquer entre les processus qu à réellement générer de nouveaux états. Une autre particularité de ce graphe est la présence d accélérations plus que linéaires, ce qui est normalement mathématiquement impossible. En fait, ces accélérations sont le résultat de spécifications impliquant des calculs et des synchronisations complexes de données. Dans ces conditions, l exécution successive de transitions du Ste devient coûteuse en temps et peut être distribuée de manière profitable sur toutes les machines. Ces accélérations supralinéaires sont également dues à des problèmes mémoires que doit faire face la version séquentielle de génération face à de larges espaces d états. Étant donné que nos accélérations sont en fonction du temps pris par la version séquentielle pour la génération du même espace d état, et que les problèmes mémoires affectent moins les machines parallèles, nous pouvons justifier ces très grandes accélérations obtenues. Une autre mesure de performance déduite de la mesure d accélération, est la mesure d efficacité de la solution parallèle. Cette performance se traduit par la formule suivante : E = S(N)/N E représente l efficacité du système à paralléliser le problème séquentiel de la génération d espace d états. Dû à l inactivité chronique des processus, aux calculs supplémentaires comparés à la solution séquentielle, et aux temps de communication, E ne peut être qu au plus autant efficace que la solution séquentielle, on a donc E 1. Ainsi, la mesure d efficacité est souvent exprimée en pourcentage, comme sur le graphe 5.4. Cependant, comme dans le cas énoncé précédemment, où les accélérations pouvaient être plus que linéaires, on peut observer des taux d efficacité supérieurs à 100%, pouvant même aller jusqu à 300% dans le

88 88 Chapitre 5. Réalisation et expérimentation 20 ALTERNATE BIT SCSI-5-7-small v2 SCSI-6-7-big v2 BRP 15 Speedup Number of Workers Figure 5.3: Accélération de la solution parallèle par rapport à la solution séquentielle cas du protocole Scsi-2 avec 6 disques. Pour des accélérations proches du linéraire, comme avec le protocole Scsi-2 avec 5 disques, l efficacité est à peu près constante proche de 100%, confirmant ainsi l utilisation bénéfique du parallélisme pour générer l espace d états. Sinon, on peut observer que le taux d efficacité a tendance à décroître avec l augmentation de machines. Combinée avec la mesure d accélération, le taux d efficacité permet de déterminer le nombre de machines optimums pour un problème et un nombre limite de machines donnés. Ainsi, elles confirment que la configuration avec 10 machines correspond à un optimum pour le protocole Brp, puisqu elle présente le meilleur speedup et une efficacité supérieure à 100%. Également déduite des mesures précédentes, il est possible de représenter le coût de notre approche parallèle selon le nombre de machines utilisées. Il s agit ici du coût par rapport au temps, dont la formule mathématique peut s exprimer de plusieurs manières différentes selon les valeurs numériques dont on dispose : C = T seq N/S(N) = T seq /E = N T par Le coût C de l algorithme parallèle est proportionnel au nombre de machines utilisées, et consiste au produit du temps mis par la solution parallèle et du nombre de machines nécessaires à cette solution parallèle. La tendance observée sur le graphique 5.5, est que le coût reste globalement constant et n augmente que très légèrement avec un nombre de machines grandissant.

89 5.3. Expérimentations 89 Efficiency(%) ALTERNATE BIT SCSI-5-7-small v2 SCSI-6-7-big v2 BRP Number of Workers Figure 5.4: Efficacité de la solution parallèle ALTERNATE BIT SCSI-5-7-small v2 SCSI-6-7-big v2 BRP Cost(sec) Number of Workers Figure 5.5: Coût engendré par la solution parallèle

90 90 Chapitre 5. Réalisation et expérimentation Passage à l échelle Dans le cadre d une solution parallèle sur architecture Mimd à mémoire distribuée telle qu une grappe de machines, il est intéressant de connaître la capacité de la solution parallèle à passer à l échelle, c est-à-dire à être aussi efficace sur un nombre grandissant de machines utilisées pour les calculs. On peut représenter cette grandeur par la formule suivante : E(p + 1) E(p) p représente un nombre fixé de machines sur lequel l efficacité E(p) a été calculée. La formule mathématique symbolise donc la capacité que l algorithme parallèle a de résoudre un problème sur p + 1 machines avec une efficacité aussi proche que possible de E(p). On peut également utiliser un pourcentage pour représenter cette valeur, le calcul sera alors P(p + 1) = E(p + 1)/E(p). Sur la figure 5.6, les valeurs trouvées se retrouvent toutes globalement autour de la valeur 100% et montrent que notre solution parallèle a de bonnes propriétés de passage à l échelle. Les différents pics ponctuels observables sur le graphe, montrent des configurations de machines particulièrement efficaces et adaptées à un protocole donné. Ainsi, pour le protocole du Bit Alterné, l utilisation de 4 machines dans la solution parallèle présente le meilleur passage à l échelle de la méthode. Cette valeur vient confirmer une situation où les coûts sont faibles (cf. fig 5.5) et où l efficacité et l accélération sont élevées (cf. fig 5.4 et 5.3). 150 ALTERNATE BIT SCSI-5-7-small v2 SCSI-6-7-big v2 BRP Scalability(%) Number of Workers Figure 5.6: Passage à l echelle de notre approche parallèle

91 5.3. Expérimentations 91 Portabilité La portabilité est une notion permettant de caractériser la capacité d un outil à fonctionner sur une grande variété d environnements matériels et logiciels. Pour être portable, un outil ne doit pas nécessiter une mécanique complexe pour son installation et son utilisation. Dans notre travail, notre volonté a été axée sur une portabilité maximale de l outil implémenté tout au long des différentes réalisations. Ainsi, seule la boîte à outils Cadp devrait à terme être installée pour que l implémentation de Distributor puisse fonctionner. Ceci est possible notamment grâce à l utilisation de sockets pour la communication inter-processus, car ce type de communication est présent sur la majorité des systèmes d exploitation. Nous utilisons par ailleurs des librairies Tcl/Tk pour le monitoring qui sont directement fournies avec Cadp. Notre outil est également facile à configurer, notamment au niveau des caractéristiques des machines superviseur et générateur. Ces considérations ont également dirigé nos choix de conception comme l utilisation de threads POSIX ou non, car toutes les architectures parallèles n acceptent pas cette norme ou alors avec des comportements différents. Pour l instant, notre système est portable sur toutes machines parallèles Mimd à mémoire distribuée, telles que les grappes de Pc ou les réseaux de station de travail, sous Linux ou Solaris, interconnectées par Ethernet. Statistiques Une autre validation, qui aurait été intéressante à faire également, était de valider chacun des composants présentés dans la section 3.2 dans le cadre de notre technique de génération, soit par des études statistiques, par exemple sur les temps nécessaires aux recherches et insertions dans les structures de données choisies, soit par des études sur la portabilité et le passage à l échelle des techniques employées, comme pour les communications. Elle a effectivement été réalisée pour certains d entre eux, comme pour la table de hachage et pour la fonction de partitionnement, mais il reste encore d autres composants à valider comme la communication par une étude sur le nombre de messages échangés par exemple Le monitoring du système Distributor La présence d un outil de visualisation de statistiques en temps-réel de la génération distribuée d espace d états a également permis d établir les études de performances précédentes. Les figures suivantes indiquent le type d information que l on peut obtenir sur le système au cours de la construction du graphe en utilisant 10 processus. Il est possible de connaître le status global du système en cours d analyse grâce aux informations contenues sur la figure 5.7 représentant une des cinq pages de visualisation accessibles par l interface. Plusieurs valeurs sont retournées comme le nombre d états explorés jusqu à présent, états appartenant à l ensemble E (cf. fig 2.1), le nombre d états visités et le nombre de transitions exécutées. De plus, des rectangles de couleur, présents dans la colonne

92 92 Chapitre 5. Réalisation et expérimentation variation, indiquent si un nœud du graphe a un ensemble d états à visiter grandissant, par la couleur verte, diminuant, par la couleur orange, ou vide, par la couleur rouge. Si tous les rectangles sont rouges, la génération est alors terminée. Notre algorithme de terminaison distribuée permet de détecter correctement cet instant là, pour arrêter la génération. Figure 5.7: Outil de visualisation de la génération distribuée (onglet 1) : vision numérique des ensembles E i, V i et T i D autres informations sont montrées par cet outil, comme l ensemble des labels rencontrés, c est-à-dire l ensemble des actions exécutées au cours de la génération (cf. fig 5.8). De tels labels sont représentés en Lotos par des synchronisations de valeurs sur des portes, comme la porte GET dans notre exemple. La figure 5.9 est très importante puisqu elle reflète la répartition des charges sur chacune des machines. On constate qu il y a un très bon équilibrage de charge effectué par la fonction de hachage statique, bien qu aucun mécanisme de rééquilibrage dynamique de charge ne soit implanté dans notre solution parallèle. Enfin, pour vision globale et résumée du système en cours d analyse, on dispose d une interface, montrée sur la figure 5.10, qui indique les nombres totaux d états explorés et visités, de transitions et des labels, en plus de valeurs moyennes que l on peut comparer avec les résultats individuels de chacune des machines. Dans l exemple présenté, les valeurs correspondent à la génération terminée du protocole du Bit Alterné avec 255 messages à émettre différents. La taille du système de transitions étiquetées engendré est, comme nous le voyons sur la figure, de plus de 6 millions d états et d à peu près 20 millions de transitions. Toutes ces considérations et expérimentations réunies permettent de confirmer les bonnes performances de notre solution parallèle. Elles nous confortent également dans les choix

93 5.3. Expérimentations 93 Figure 5.8: Outil de visualisation de la génération distribuée (onglet 2) : énumération des labels rencontrés globalement par le système Figure 5.9: Outil de visualisation de la génération distribuée (onglet 3) : équilibrage de charge entre les machines

94 94 Chapitre 5. Réalisation et expérimentation Figure 5.10: Outil de visualisation de la génération distribuée (onglet 4) : informations globales sur l état du système conceptuels qui ont été pris, notamment concernant la portabilité et le passage à l échelle de notre méthode. Notre outil est ainsi robuste et montre que la génération explicite d états est appropriée pour des systèmes massivement parallèles, bien qu il y ait des dépendances entre les transitions du Ste généré. Des gains significatifs ont été obtenus en matière de mémoire et de temps, et montrent l utilité d une telle approche parallèle pour la vérification explicite par modèles de systèmes. Notre solution repousse les limites des tailles des systèmes jusqu alors analysés et apporte ainsi un moyen efficace de pallier au problème de l explosion d espace d états.

95 Chapitre 6 Conclusion Pour résumer les avancées apportées par nos travaux, nous pouvons les scinder en deux parties, l une sur les réalisations théoriques, et l autre sur les réalisations pratiques. Concernant les aspects théoriques, la principale avancée consiste en des améliorations algorithmiques dans la construction parallèle de l espace d états d un système. Nous avons d abord effectué une étude bibliographique complète des différentes techniques de génération distribuées d espace d états dans le cadre de la vérification explicite basée sur les modèles. Nous avons mené une analyse comparative des différents composants algorithmiques présents dans ces techniques, suite à laquelle nous avons construit notre solution parallèle, concrétisée par la conception de deux algorithmes. Ces deux algorithmes ont été spécifiés formellement en Lotos afin de vérifier des propriétés de sûreté et de vivacité sur notre solution parallèle. Cette phase de vérification nous a permis de conclure que notre méthode a un comportement adaptée, répondant au problème de la génération parallèle d espace d états. Des travaux innovants ont été réalisés concernant la gestion distribuée de type de données dynamiques, notamment la définition de plusieurs algorithmes et l intégration de l un deux à l outil. Nous avons mis en place un processus superviseur ayant un rôle clairement défini dans la génération, apportant une robustesse accrue à l outil et des mécanismes d évaluation de performances de l outil pour l utilisateur. Pour résoudre le problème du surcoût engendré par les communications dans la parallélisation de la génération de l espace d états, nous avons établi différentes stratégies de communication avec une refonte complète des primitives de communication, les rendant génériques, pour permettre une meilleure portabilité et un meilleur passage à l échelle de l outil. Du côté expérimentation, nous avons implémenté une solution complète à base de passage de messages par sockets non-bloquantes. Cette solution est fondée sur une refont des primitives de communication au sein d une bibliothèque réutilisable par d autres outils, pour une meilleure modularité de notre prototype de génération distribuée d espace d états, et un meilleur passage à l échelle sur les grappes de machines. La nouvelle implémentation du prototype bénéficie également de la simplicité, de la correction et de l efficacité des algorithmes améliorés. Elle est supportée par les grappes de stations de travail ou de Pc, utilisant les systèmes d exploitation Solaris ou Linux, et notre approche parallèle présente une très 95

96 96 Chapitre 6. Conclusion bonne portabilité et robustesse. Perspectives Notre outil de génération distribuée d espaces d états développé avec la grappe de Pc pourrait faire l objet d une utilisation dans d autres contextes. Le développement du metacomputing, dont les prémisses sont le calcul sur Internet de type SETI@home ou bien le calcul sur grilles de grappes, offre un potentiel de puissance de calcul et de ressources encore bien plus important que celui des simples grappes et permettrait d augmenter grandement la cardinalité et la vérification de modèles formalisés. Pour ce faire, les procédures d exploration de graphes doivent être adaptées à une utilisation extérieure et hétérogènes des ressources informatiques, et constituerait une bonne continuation de nos travaux. Parmi les différentes directions de poursuite de travaux sur la génération distribuée d espace d états, on peut citer : L approche multithreadée pour que le système puisse palier au problème des communications et de l ordonnancement des tâches par un recouvrement complet des communications par du calcul. Cette approche est également bonne pour l hétérogénéité des processeurs. La tolérance aux pannes des protocoles distribués ou centralisés par rapport à des défaillances au niveau des connections (fiable ou non fiable) ou au niveau des processus (fiable ou non fiable). En effet, des problèmes apparaissent dans notre solution Distributor si les canaux de communication ne sont pas FIFO ou que les communications ne sont pas fiables, c est à dire si des pertes de messages peuvent survenir. Les différents protocoles distribués, nécessitant l envoi et la réception de messages, sont basés sur l hypothèse que les canaux sont FIFO et que les communications sont fiables. Parmi ces protocoles, la terminaison et la représentation canonique de termes ou labels sont les plus concernés par le respect de l ordre des messages sur les canaux, et donc de leur ordre d arrivée sur le processeur visé. Si cette hypothèse est brisée, alors le comportement général de la génération est imprédictible. La tolérance aux défaillances du support de communication, bien qu intéressante, était au-delà du cadre de notre travail. Ce constat a toutefois son importance pour des travaux futurs puisqu il met en avant des limites possibles de notre système. L extension de notre méthode à des réseaux d architectures hétérogènes pour que notre solution puisse être facilement utilisée sur le parc de machines que possèdent les laboratoires ou les entreprises. Les problèmes ainsi soulevés touchent à la fois des questions d ordre matériel, comme des vitesses de processeurs ou de réseaux d interconnexion qui diffèrent, et d ordre logiciel, comme la couche Tcp/Ip utilisée dans nos communications ou tout simplement les données utilisées qui sont différentes entre les architectures Sparc et Intel par exemple.

97 Une autre spécification formelle que nous voulions établir de notre algorithme Distributor était de modéliser l approche multi-threadée du système par des spécifications Lotos correspondantes, afin de faire refléter les deux mécanismes possibles de gestion de la communication : le mécanisme consistant au recouvrement de la communication par des calculs grâce à des threads indépendants, et l autre consistant à la séquentialisation des opérations de calculs et de gestion des messages. Il est très facile d exécuter des automates en parallèle dans Lotos par le simple appel à des mécanismes les faisant synchroniser sur toutes ( ) ou aucune ( ) portes. Cette formalisation pourrait faire l objet de plus complètes vérifications formelles de nos algorithmes au niveau des communications. Une autre perspective immédiate de nos travaux de réalisation est l intégration de notre protocole de cohérence des labels et des termes décrit dans le chapitre 3 en section 3.3. Des travaux ont été entrepris pour rendre l implémentation de la gestion des données dynamiques modulaire. En effet, les différentes améliorations concernant les mécanismes de stockage, de recherche et d insertion des labels sont très importants pour les autres outils de la plate-forme Cadp qui utilisent également des labels, tels que Generator, Evaluator et Bisimulator pour ne citer qu eux. Elles permettraient des gains à la fois en temps de calcul et en place mémoire pour la gestion des labels. Mais cette intégration du protocole est dépendante d une extension de l environnement Cadp par le développement d outils complémentaires, notamment pour le stockage des labels et des termes, qui sont en cours d implémentation et de tests, nous limitant de ce fait dans nos réalisations. Finalement, étant donné que les tailles des Ste construits par Distributor augmentent de plus en plus, il deviendra nécessaire de paralléliser les algorithmes de vérification euxmêmes. Deux approches pourront être entrevues : des algorithmes parallèles opérant à la volée durant l exploration du Ste, ou des algorithmes séquentiels travaillant sur le Ste partitionné préalablement construit. 97

98 98 Chapitre 6. Conclusion

99 Appendix A État de l art : analyse bibliographique comparative 99

100 100 Appendix A. État de l art : analyse bibliographique comparative

101 101

102 102 Appendix A. État de l art : analyse bibliographique comparative

103 103

104 104 Appendix A. État de l art : analyse bibliographique comparative

105 105

106 106 Appendix A. État de l art : analyse bibliographique comparative

107 107

108 108 Appendix A. État de l art : analyse bibliographique comparative

109 109

110 110 Appendix A. État de l art : analyse bibliographique comparative

111 111

112 112 Appendix A. État de l art : analyse bibliographique comparative

113 113

114 114 Appendix A. État de l art : analyse bibliographique comparative

115 115

116 116 Appendix A. État de l art : analyse bibliographique comparative

117 117

118 118 Appendix A. État de l art : analyse bibliographique comparative

119 119