aris 6 France Telecom CNET - olivier.potonniee.online.frolivier.potonniee.online.fr/public/docs/These.pdf · L’utilisation de l’approche synchrone dans la programmation des systèmes

aris 6 France TelecomCNET

THESE

par

Olivier Potonniée

Pour obtenir le titre de

DOCTEUR DE L’UNIVERSITE PARIS VI

Spécialité : INFORMATIQUE

Etude et prototypage en ESTEREL dela gestion de processus d’un micro-

noyau de système d’exploitationréparti avec garantie de service

Soutenue le 02 avril 1996, devant le jury composé de :

Président Claude GIRAULTRapporteurs Roland BALTER

Jean-Paul RIGAULTExaminateurs Charles ANDRE

Michel GIENFrançois HORNSacha KRAKOWIAKJean-Bernard STEFANI

Gestion de processus d'un micro-noyau de système d'exploitation réparti avec garantie de service

Remerciements

Je tiens à remercier

Monsieur Jean-Bernard Stefani, pour m’avoir accueilli dans son équipe, etencadré dans ce travail. Ses conseils et suggestions m’ont été précieux.

Monsieur Claude Girault, qui m’a fait l’honneur de présider le jury de cettethèse.

Messieurs Jean-Paul Rigault et Roland Balter, pour avoir accepté d’êtrerapporteurs. Leurs commentaires sur mon document m’ont aidé à le faireprogresser.

Messieurs Charles André, Michel Gien, François Horn et Sacha Krakowiak,pour leur participation au jury.

Tous les membres de l’équipe Arcade du CNET, pour la qualité de leur accueil,et particulièrement Laurent Hazard et François Horn pour le temps qu’ils m’ontconsacré.

France Telecom, qui a financé cette thèse.

i


ii


Résumé

L’utilisation de l’approche synchrone dans la programmation des systèmesd’exploitation permet d’obtenir une plate-forme déterministe et prouvée pour bâtirdes applications temps-réel.

Cette thèse présente une réalisation modulaire de la gestion des tâches à l’aidedu langage synchrone ESTEREL. Nous montrons quelques types de proprietes non-triviales qui ont pu etre verifiees automatiquement sur le code ESTEREL. Nousdéfinissons la machine d’exécution nécessaire à son fonctionnement, et endécrivons une implantation expérimentale.

Nous montrons comment, dans une configuration répartie, plusieursexemplaires de cette gestion des tâches peuvent être synchronisés, ceci afin d’offrirun exécutif synchrone réparti, qui facilite la réalisation des applications temps-réeldistribuées.

Mots clefs : Programmation synchrone, systèmes répartis, gestion de tâches,systèmes déterministes, systèmes temps-réel

Abstract

Study and prototyping in Esterel of process management in a distributedoperating system’s microkernel with service guarantees.

The use of the synchronous programming approach in operating systemsimplementation allows the construction of provable, deterministic platforms tosupport real-time applications.

This thesis describes a modular process management written in Esterel, asynchronous programming language. We present non-trivial properties that havebeen verified automatically on the Esterel code. The execution machine necessaryto support its correct behavior is defined, and we describe an implementation of it.

We also present how several instances of this process management can besynchronized in a distributed context, yielding a synchronous platform that shouldfacilitate the development of distributed real-time applications.

Key words : Synchronous programming, distributed systems, processmanagement, real-time systems, deterministic systems

iii


iv Table des matières


Table des matières

Table des matières................................................................................................... v

Introduction ............................................................................................................. 1

1. Objectifs et état de l’art .................................................................................... 7

1.1. Présentation d’ODP..................................................................................... 7

1.1.1. Définitions ....................................................................................... 81.1.2. Les points de vue de RM-ODP ........................................................ 9

1.1.2.1. Le point de vue des traitements ....................................... 91.1.2.2. Le point de vue d’ingénierie ............................................ 11

1.1.3. Les fonctions ODP ......................................................................... 111.1.4. Les bienfaits du modèle................................................................. 12

1.2. Réalisation d’un plate-forme ODP avec garantie de service .................... 12

1.2.1. Gestion de la QoS .......................................................................... 121.2.1.1. Du point de vue des traitements : Spécification de QoS 131.2.1.2. Aspect d’ingénierie : traitement des contraintes de QoS15

1.2.2. Gestion du contrôle........................................................................ 171.2.2.1. Du point de vue des traitements : l’approche synchrone 171.2.2.2. Aspect d’ingénierie : exécution des objets de contrôle.... 201.2.2.3. Aspect technologique : choix du langage ........................ 21

1.2.3. Les micro noyaux : Evolutifs et modulaires.................................. 21

1.3. Comparaison avec d’autres travaux.......................................................... 23

1.3.1. Mars ............................................................................................... 241.3.2. Arts ................................................................................................ 251.3.3. Spring............................................................................................. 261.3.4. Maruti ............................................................................................ 281.3.5. Delta-4 ........................................................................................... 291.3.6. CHAOSarc ..................................................................................... 291.3.7. Bilan............................................................................................... 30

1.4. Problématique et plan ............................................................................... 31

1.4.1. Gestion synchrone des tâches ....................................................... 311.4.2. Synchronisation répartie............................................................... 33

2. Gestion synchrone des tâches....................................................................... 37

2.1. Portée de l’étude ........................................................................................ 37

Table des matières v


2.2. La gestion des tâches Chorus.................................................................... 38

2.2.1. Les interruptions ........................................................................... 382.2.1.1. Origine des interruptions................................................ 382.2.1.2. Synchronisme / asynchronisme des interruptions ......... 39

2.2.2. Les threads, leur vie ...................................................................... 402.2.2.1. Les états d’un thread Chorus.......................................... 412.2.2.2. Les événements ............................................................... 42

2.2.3. L’ordonnancement ......................................................................... 442.2.4. La gestion du temps ...................................................................... 442.2.5. Synchronisation dans le noyau ..................................................... 45

2.2.5.1. Verrouillage du noyau..................................................... 452.2.5.2. Gestion des threads......................................................... 452.2.5.3. Gestion des interruptions ............................................... 462.2.5.4. Gestion du temps............................................................. 47

2.3. Modélisation .............................................................................................. 47

2.3.1. Objectifs ......................................................................................... 472.3.2. Définitions ..................................................................................... 482.3.3. Présentation des composants ........................................................ 482.3.4. Vérifications................................................................................... 50

2.3.4.1. Vérifications graphiques ................................................. 512.3.4.2. Vérifications formelles .................................................... 51

2.3.5. Les interruptions : composant Interrupt ...................................... 532.3.5.1. Le module InterruptMgr ................................................. 542.3.5.2. Le module SysMode......................................................... 58

2.3.6. La gestion du temps : composant TimeMgr.................................. 592.3.6.1. Gestion des timers : module TimerMgr.......................... 602.3.6.2. Gestion de l’interruption horloge : module TimeGuard . 61

2.3.7. Les états d’un thread : Composant Thread .................................. 622.3.7.1. Gestion des suspensions : module thSuspend ................ 632.3.7.2. Gestions des arrêts : module thStop............................... 642.3.7.3. Gestion des attentes : module thSleep ........................... 672.3.7.4. Gestions de l’état global : module thMain ...................... 702.3.7.5. Gestions du mode d’exécution : module thTrapExc ....... 72

2.3.8. L’ordonnancement : composant Scheduler ................................... 742.3.8.1. Ordonnancement générique : module SchedBase .......... 762.3.8.2. Gestion du temps partagé : module TimeSlice............... 79

2.3.9. Récapitulatif .................................................................................. 81

2.4. Conclusion.................................................................................................. 82

3. Mise en oeuvre du modèle.............................................................................. 83

3.1. Composition des modules .......................................................................... 83

3.1.1. Le séquencement synchrone.......................................................... 843.1.2. Le parallèle asynchrone ................................................................ 853.1.3. Application à la gestion des tâches ............................................... 85

3.2. Machine d’exécution .................................................................................. 87

vi Table des matières


3.2.1. Collecteur d’événements d’entrée externes .................................. 883.2.2. Constructeur de l’événement de réaction ..................................... 883.2.3. Exécution d’une transition ............................................................ 893.2.4. Collecteur de l’événement sortant ................................................ 913.2.5. Emetteur d’événements de sortie.................................................. 913.2.6. Analyse de la durée des réactions................................................. 92

3.2.6.1. Réaction d’un objet synchrone ........................................ 923.2.6.2. Réaction de l’ensemble des objets synchrones................ 93

3.2.7. Communications............................................................................ 94

3.3. Comment ça se passe ? .............................................................................. 94

3.3.1. Un exemple .................................................................................... 943.3.2. Commentaires................................................................................ 95

3.4. Implantation du système .......................................................................... 96

3.4.1. Objectif et choix d’implantation .................................................... 963.4.2. Interfaces de la gestion des tâches................................................ 98

3.4.2.1. Interface utilisateur ........................................................ 983.4.2.2. Interface avec le noyau.................................................. 100

3.4.3. Exécution des réactions du noyau synchrone ............................. 1003.4.4. Transmission des interruptions au SVP..................................... 1013.4.5. Performances ............................................................................... 102

3.4.5.1. Taille du code................................................................. 1023.4.5.2. Temps d’exécution ......................................................... 1033.4.5.3. Optimisations ................................................................ 104

3.5. Conclusion................................................................................................ 108

4. Exécutif synchrone réparti.......................................................................... 111

4.1. Les modèles des objets réactifs répartis ................................................. 111

4.2. Le modèle synchrone faible ..................................................................... 113

4.2.1. Le modèle sémantique................................................................. 1134.2.2. Le modèle d’exécution ................................................................. 114

4.3. Application à la gestion des tâches ......................................................... 118

4.3.1. Comportement temporel.............................................................. 1184.3.2. Les communications entre les tâches ......................................... 119

4.3.2.1. Intégration dans le micro-noyau synchrone ................. 1204.3.2.2. Intégration dans les SVP .............................................. 1224.3.2.3. Interface utilisateur ...................................................... 122

4.3.3. Le déclencheur de réaction.......................................................... 1234.3.3.1. Le déclencheur de base ................................................. 1244.3.3.2. Le déclencheur synchronisé à vague ............................ 1244.3.3.3. Le déclencheur parsemé................................................ 126

4.4. Démonstration du synchronisme de l’exécutif........................................ 127

4.4.1. Présentation de l’application “Tortues” ...................................... 127

Table des matières vii


4.4.2. Fonctionnement de la démonstration ......................................... 1284.4.3. Résultats ...................................................................................... 129

4.4.3.1. Sur un exécutif non synchronisé................................... 1304.4.3.2. Sur un exécutif synchronisé par déclencheur à vague . 1314.4.3.3. Sur un exécutif synchronisé par déclencheur clairsemé132

4.5. Conclusion................................................................................................ 134

Conclusion et perspectives................................................................................ 135

Bibliographie........................................................................................................ 139

Annexes.................................................................................................................. 145

1 Chorus......................................................................................................... 145

2 Le langage synchrone Esterel .................................................................... 148

2.1 Les entrées d’un programme Esterel................................................ 1482.2 Les primitives Esterel ....................................................................... 148

2.2.1 Les primitives impératives ........................................... 1482.2.2 Les primitives temporelles............................................ 1492.2.3 L’exécution de tâches asynchrones ............................... 151

2.3 Les paradoxes temporels................................................................... 1522.4 La compilation d’un programme Esterel .......................................... 152

3 Code Esterel de la gestion des tâches ........................................................ 154

viii Table des matières


Introduction

Un système temps-réel est un système permettant aux utilisateurs de définirdes contraintes temporelles à l’exécution de leurs programmes. Ainsi pour exécuterun programme, il est nécessaire d’avoir connaissance des contraintes liées à cetteexécution, et de pouvoir analyser leur incidence sur le système : peut-on accepterd’exécuter une tâche, faut-il pour cela effectuer des modifications del’environnement, des réservations de ressources ? La relation qui se crée entre lesystème et le programme qu’il exécute, ou entre un serveur et son client, est uncontrat dans lequel chacune des parties doit garantir des propriétés, en échange dequoi elle attend des propriétés déterminées dans ses interactions avec l’autrepartie. Les propriétés désignées par ces contrats ne sont pas fonctionnelles, maisqualitatives, nous les appelons Qualité de Service. Par exemple, dans le cas d’unprogramme demandant au système de l’exécuter en moins de 1 seconde, le contratpourra être : “le système s’engage à exécuter le programme P en moins de 1seconde si celui s’engage à ne pas utiliser plus de 500 milli-secondes pendant cettepériode”. Pour pouvoir garantir de tels contrats, il est nécessaire d’avoir uneconnaissance profonde des composants impliqués, tant d’un point de vue desperformances que du comportement : P doit savoir quel est son temps d’exécutionau pire (performance), et le système doit pouvoir en déduire la garantie qu’il peutfournir en fonction de cette valeur (comportement et performance). D’autre part ilest nécessaire d’identifier les événements du système sur lesquels vont s’appliquerles contraintes de qualité de service. Ces événements pourront alors être observéspendant l’exécution, afin de vérifier le respect du contrat.

Un système temps-réel est un système réactif, c’est-à-dire qu’il réagitcontinûment à son environnement en contrôlant l’exécution des différentséléments du système. Il assure aussi une fonction transformationnelle, réalisantles calculs et autres traitements de données. Il apparaît donc naturel de réaliserun système temps-réel à l’aide d’une combinaison d’objets transformationnels etréactifs.

Les objets réactifs gèrent la synchronisation et le contrôle des événements seproduisant dans le système. Leur interface est constituée de deux ensemblesd’événements : ceux auxquels ils réagissent, et ceux qu’ils produisent enconséquence. Ces événements définissent clairement les points de contrôle dusystème, sur lesquels vont porter les contraintes de qualité de service. Un objetréactif dispose d’un temps logique discret : il est stimulé par l’occurrence d’un ou

Introduction 1


plusieurs événements à son entrée, et ses réactions constituent les instants dutemps logique.

Les langages synchrones ont été créés pour programmer les systèmes réactifs.Leur sémantique en reprend les concepts, et y ajoute celui de l’instantanéité desréactions : les calculs et communications internes qui s’y produisent sontimmédiats, et les événements en sortie sont disponibles en même temps que lesévénements d’entrée qui les génèrent. Dans la pratique, aucune machine n’étantinfiniment rapide, cette hypothèse est vérifiée tant que l’objet réagit aussi vite queles événements qu’il traite.

Les langages synchrones sont déterministes, c’est-à-dire que dans un étatdonné, une stimulation d’un objet réactif avec un ensemble d’événements en entréeproduira toujours le même ensemble d’événements en sortie. Ces langagespossèdent une sémantique qui permet d’obtenir une description formelle ducomportement des objets réactifs. Des outils mathématiques peuvent alors êtreutilisés pour vérifier et prouver leur comportement. Cette propriété est essentiellepar rapport aux outils de programmation classiques, qui nécessitent de réécrire lesprogrammes sous une autre forme (un autre formalisme) pour pouvoir démontrerleur comportement.

Cette thèse porte sur la partie contrôle des systèmes temps-réel. Nous yparlerons donc de la mise en oeuvre des objets réactifs. Les autres aspects dusystème n’y seront présentés que pour expliquer comment notre travail s’intègredans une approche globale de la réalisation d’un système avec garantie de qualitéde service.

L’intérêt de la programmation synchrone a été mise en évidence dans denombreuses études [LEB89][CAS94][CRE95][MRS95]. Nous allons l’utiliser dansun domaine où elle n’est pas encore présente : la réalisation des systèmesd’exploitation.

Objectifs

Nous nous proposons d’utiliser la programmation par objets réactifs dès le plusbas niveau du système d’exploitation. Nous obtiendrons ainsi un système dont onpourra fournir une description formelle, directement à partir de son code, et dontle comportement sera prouvé. Aucun système actuel ne dispose de cette propriété.

L’utilisation de la notion d’objet nous permet d’encapsuler des entitésfonctionnelles du système d’exploitation, et de définir une interface indépendantedes détails de son fonctionnement. Ainsi il devient possible de modifier un élémentdu système sans avoir à toucher aux autres composants. Cette modularisation dela conception du système a déjà été utilisée dans des travaux tels que ARTS[TOK89], SPRING [STA89], MARUTI [NIR90], ou CHAOS [GOP89]. Toutefois notreapproche permet plus de souplesse, car les objets n’ont pas à connaître ceux aveclesquels ils vont communiquer. Dans le cas des objets classiques, un objet, pourcommuniquer, doit explicitement faire une invocation à une interface d’un autreobjet. Ceci implique une connaissance préalable de l’environnement dans lequel il

2 Introduction


va s’exécuter. Cette contrainte n’existe plus dans notre cas. Les objets réactifsdisposent de signaux en entrée et en sortie. La communication entre deux objetsréactifs est assurée par la connexion d’un signal de sortie de l’un à un signald’entrée de l’autre. L’ajout d’une nouvelle fonction du système est réalisé par lacréation d’un ou plusieurs objets réactifs, qui s’insèrent dans le reste du systèmeen se connectant aux signaux qui les concernent, sans que les autres éléments dusystème aient besoin d’en être informés.

La réalisation de la totalité d’un noyau de système d’exploitation étant untravail énorme, nous n’étudierons dans cette thèse qu’un de ses aspects : la gestiondes tâches. La réalisation d’un prototype de cette fonction du système valideranotre approche en montrant sa faisabilité. Ce prototype sera implanté au niveauutilisateur, réalisant donc une gestion synchrone de tâches utilisateurs. Le choix dece type d’implantation est dicté par deux contraintes : nous ne disposons pas dureste du système réalisé conformément à notre approche, et son intégration dansun système actuel est difficile, en raison du manque de séparation claire entre lesdifférents composants des systèmes dont nous disposons.

La mise en oeuvre d’objets réactifs nécessite un support d’exécution, qui a pourrôle de faire le lien entre les mondes synchrone et asynchrone, et de veiller aurespect de la sémantique synchrone. Cette fonction recouvre en particulier latraduction entre événements du monde asynchrone et signaux du langagesynchrone, la communication des événements entre les différents objetssynchrones, et l’exécution de leurs réactions. Nous appellerons ce support lamachine d’exécution synchrone. Des études ont été menées pour définir quelle estla gamme des services que doit offrir cette machine d’exécution [ARC95], mais lesspécificités de nos objets réactifs, c’est-à-dire leur localisation au niveau le plus basdu système, vont nous amener à adapter sa structure.

Dans un cadre centralisé, la réalisation d’un tel environnement d’exécution estrelativement maîtrisée. Toutefois un grand nombre de systèmes informatiquessont répartis, soit en raison de la disparité géographique des éléments qu’ilscontrôlent, soit dans un souci de performance (mise en parallèle) et/ou de sécurité(duplication). Il est alors nécessaire de définir une machine d’exécution permettantde reconstituer le synchronisme d’un groupe d’objets réactifs répartisinteragissant. Imaginons une configuration d’un ensemble de sites exécutantchacun un système d’exploitation dont le noyau contient notre gestion synchronedes tâches. Nous allons montrer dans cette thèse comment la synchronisation deces noyaux permet de constituer un exécutif synchrone réparti, offrant une base desynchronisation au niveau applicatif.

Voici un exemple montrant l’intérêt d’un tel exécutif. Considérons le cas d’uneapplication mettant en jeu trois machines. L’une (M1) effectue une captureaudio/vidéo, et les deux autres (M2 et M3) exécutent un traitement sur cetteinformation : la restitution audio sur M2, et la visualisation de la vidéo sur M3.Nous souhaitons mettre en oeuvre une synchronisation des traitements sur lesmachines M1 et M2, afin qu’il n’y ait pas de décalage entre l’image et le son. Enutilisant l’approche synchrone nous réaliserons le contrôle d’une telle application àl’aide de cinq objets réactifs, de la façon suivante :

Introduction 3


Ecran

M1

M3

M2

HautParleur

AudioIn

VideoIn

SyncAV

AudioOut

VideoOut

Contrôle d’une application multimédia répartie

Sur la machine M1, les objets AudioIn et VideoIn communiquent lesinformations en provenance de leurs capteurs respectifs. Ces deux capteurspeuvent ne pas avoir la même durée de traitement : une donnée vidéo saisie à ladate t pourra être émise en sortie de VideoIn à la date t+300ms, alors que le délaisera de 500ms pour la capture audio. L’objet SyncAV synchronise et ré-émet cesdeux flux d’informations. Pour cela il retarde la ré-émission du flux le plus rapide.Lorsqu’il émet simultanément une donnée audio et une donnée vidéo, elles doiventêtre restituées au même moment.

Comme on peut le voir, le problème est traité en faisant abstraction del’asynchronisme des communications, tel qu’il le serait de façon centralisée. Onattend donc de l’exécutif sous-jacent qu’il nous assure que les informations enentrée de deux objets réactifs de restitution (AudioOut et VideoOut) sont traitéessimultanément. Nous le qualifierons alors d’exécutif synchrone réparti.

Une autre approche de ce problème aurait été de répartir l’objet SyncAV, quiaurait alors contenu AudioOut et VideoOut. Des études ont été menées, qui ontrendu possibles l’exécution répartie d’objets réactifs [GIR94]. Deux raisons nousfont préférer notre solution :

• La séparation entre le contrôle et les communications y est plus claire, lesévénements liés aux communications sont visibles (observables etcontrôlables) par le système comme n’importe quel événement de notremodèle, puisqu’ils se trouvent à l’interface des objets.

• Elle est plus modulaire, car la configuration peut être modifiée sans avoir àtoucher au code des objets réactifs. En effet, il est possible et simple derajouter (éventuellement dynamiquement) des machines de restitutionaudio ou vidéo, en les connectant à l’objet SyncAV.

Pour réaliser notre exécutif synchrone réparti, nous utiliserons le modèlesémantique COREA développé dans le projet SATURNE [ADE93]. Il se base sur ladouble sémantique de la diffusion et du synchronisme faible introduit par R.Milner [MIL83] : un signal émis par un objet réactif est perçu simultanément par

4 Introduction


tous les objets réactifs exactement une unité de temps après son émission. Cecisuppose l’existence d’une base de temps commune, qui peut être établie par unprotocole de synchronisation. Le coût, en temps et en messages, des protocolesclassiques par échanges de messages est tel que nous proposons une autresolution : construire la base de temps en nous basant sur un protocole desynchronisation d’horloges, et la connaissance du délai maximum decommunication des signaux sur le réseau.

Nous appliquerons le modèle proposé à notre gestion des tâches, qui prendraalors en compte des événements répartis, traités simultanément par l’ensembledes machines interconnectées. Nous ajouterons pour cela à notre gestion destâches un mécanisme permettant aux threads de communiquer par messages, defaçon transparente à leur localisation. Les réactions des noyaux étantsynchronisées, et leurs communications respectant le modèle COREA, nous seronsassurés que tous les noyaux prendront en compte simultanément le même messageémis par l’un d’eux, et d’autre part qu’ils posséderont tous le même historique deces messages.

Il devient alors possible de bâtir des applications réactives, utilisant cemécanisme de communication, qui bénéficieront de la synchronisation sous-jacente. Dans un contexte local déterminé, garantissant un délai entre la prise encompte des messages par le noyau et leur délivrance aux threads (qui dépend de lapolitique d’ordonnancement de ces threads), on disposera d’une synchronisation auniveau applicatif.

Plan

Dans le chapitre 1, nous présenterons en détail l’approche globale de laconception d’un système réparti avec garantie de services dans laquelle se situenotre travail. Puis nous définirons la contribution de cette thèse à cette réalisation.

Le chapitre 2 traitera de la gestion des tâches. Nous commencerons par yprésenter une gestion des tâches, celle du système CHORUS, qui sera notre modèle.Nous montrerons alors un découpage en modules synchrones de cette fonction dusystème, et nous présenterons les preuves qui peuvent en être faites.

La mise en oeuvre du code Esterel de la gestion des tâches fait l’objet duchapitre 3. Elle sera traitée en deux parties :

1. Les caractéristiques nécessaires de sa machine d’exécution synchroneseront présentées, indépendamment de toute implantation. Cettedescription pourra en particulier servir de guide pour l’implantation denotre gestion des tâches dans un noyau de système d’exploitation.

2. Le cas particulier de l’implantation au niveau utilisateur sera décrit.

Nous donnerons enfin des éléments de performances de notre système. Celles-cisont actuellement décevantes, nous en expliquerons les raisons, qui tiennent nonpas à l’approche mais aux outils que nous avons utilisés.

Introduction 5


Le chapitre 4 présentera le problème de la réalisation d’un exécutif synchroneréparti. Il décomposera sa solution en deux aspects : le premier du point de vuesémantique, le second du point de vue de l’exécution. Nous présenterons lesmodifications à apporter à notre gestion des tâches et à sa machine d’exécutionpour qu’elles réalisent cet exécutif.

6 Introduction


Chapitre 1.

Objectifs et état de l’art

Un système temps-réel est un “système informatique dont les utilisateurspeuvent spécifier leurs besoins en temps et performances, et obtenir des garantiessur la réalisation de ces contraintes” [FER90]. Cette définition met en avant lanotion de contrat entre l’utilisateur, le client, et le système, qui fournit un service.Ce contrat fait apparaître des besoins, qui sont l’expression d’une qualité deservice requise par le client, et les garanties, qui définissent dans quelle mesureces besoins seront respectés par le service.

La qualité de service est définie en identifiant des événements du système, eten stipulant des propriétés sur ces événements. On pourra, par exemple, fixer undélai maximum entre la demande d’une opération et la disponibilité de sonrésultat. La façon dont se produisent ces événements représente le comportementdu système, et la problématique d’une exécution temps-réel va être d’assurer lecontrôle de ce comportement.

Nous adoptons donc une approche de la conception d’un système temps-réelbasée sur la séparation de la gestion de la Qualité de Service (QoS) et du contrôledu système [ARC95].

Temps-réel = QoS + Contrôle

Une telle approche requiert de déterminer les événements sur lesquels vontporter les contraintes de QoS et le contrôle. Nous souhaitons disposer d’une visiondu système identifiant ses composants et la nature de leurs interactions. Pour celanous adopterons le modèle de référence ODP, que nous décrirons dans le prochainparagraphe, pour d’une part offrir une présentation claire du système que noussouhaitons réaliser, et d’autre part disposer d’une grille de comparaison dessystèmes actuels.

1.1. Présentation d’ODP

La complexité croissante des systèmes informatiques amène à gérer desenvironnements répartis utilisant des technologies hétérogènes, dont laconfiguration est vouée à évoluer progressivement, et dont tous les composantsdoivent pouvoir coopérer harmonieusement.

Objectifs et état de l’art 7


Cette situation appelle à définir des concepts et des règles partagés par tous lesacteurs du développement des systèmes. Cette approche permet la conception desystèmes ouverts, qui sont conçus conformément à des standards reconnus partous. Ces standards définissent les protocoles et interfaces que doivent posséderles systèmes, ils doivent être suffisamment abstraits pour permettre desimplantations variées, mais assez directifs pour que des éléments réalisésséparément puissent coopérer. Ces définitions ne doivent pas faire de suppositionssur l’infrastructure des systèmes, permettant ainsi de réaliser des instances dustandard en fonction de la configuration matérielle et logicielle de base.

Cette approche doit permettre d’isoler les éléments d’hétérogénéité dans lesystème, et d’en proposer une encapsulation dans des services communs quiassureront différents types de transparence. Par exemple, le codage des donnéespar une machine donnée sera masqué à l’application par un service permettant ladescription de ces données à l’aide de types génériques, et le codage/décodage deces données lors de leur communication d’une machine à une autre. Latransparence alors assurée est celle de la représentation interne des données.

De telles spécifications constituent un modèle conceptuel auquel se réfèrent lesréalisateurs des systèmes. Leur lecture du modèle est dépendante de leur domained’activité, un technicien n’en a pas la même vision qu’un gestionnaire. C’estpourquoi il est nécessaire d’offrir plusieurs points de vue de ce modèle, ayantchacun un vocabulaire et une approche du problème traité pertinente pour lelecteur cible. L’existence de ces différents points de vue permet de s’assurer quetous les aspects du système sont capturés par le modèle.

L’architecture des systèmes répartis ouverts fait déjà l’objet de nombreusesrecherches et normalisations internationales bien avancées. On peut citer parexemple le projet européen ANSA (ANSAWare), et les consortiums internationauxOMG (Corba) et ODP (ODP-RM) qui se consacrent à ce domaine. La normeinternationale ODP [90295][90395] fournit un cadre conceptuel pour spécifierrigoureusement une architecture de systèmes répartis en environnementhétérogène. La description du modèle de référence ODP (ODM-RM) qui suit estfortement inspirée de [FAU94], auquel on pourra se référer pour une explicationplus détaillée de la norme.

1.1.1. Définitions

L’architecture de systèmes est la discipline dont l’objectif consiste à définir lesconcepts (classes d’objets de base) et règles (liens entre ces classes) qui régissent laconformité d’un système complexe par assemblage d’éléments de base.

Une architecture peut être considérée de différents points de vue, chacundonnant une vision totale de l’architecture, en s’intéressant à un aspectparticulier. Par exemple, on peut s’intéresser aux flux d’informations, et doncdécrire uniquement le cheminement des données dans toute l’architecture.

Il est nécessaire de disposer de fonctions pour concevoir et construire desapplications conformes à l’architecture.

8 Objectifs et état de l’art


L’ODP-RM normalise des points de vue, prescrit des modèles permettant despécifier les principes et les règles de conformité adoptés dans chaque point de vue,et identifie les fonctions nécessaires à la réalisation d’applications répartiesouvertes.

1.1.2. Les points de vue de RM-ODP

Cinq points de vue sont définis.

1. Le point de vue de l’entreprise : il exprime les objectifs, les droits et lesobligations des entités qui composent une application.

2. Le point de vue de l’information : il exprime la sémantique de l’application àl’aide de structures de données, de fonctions les manipulant et de propriétésd’intégrité sur ces données.

3. le point de vue des traitements : il exprime une vision fonctionnelle del’application à des fins de répartition en (i) définissant des entitésfonctionnelles, (ii) en précisant leurs interactions et (iii) en déterminant lespropriétés des fonctions correspondantes.

4. Le point de vue de l’ingénierie : il décrit les fonctions et services de base quedoit fournir l’infrastructure d’exécution pour que l’on puisse construire lesmécanismes assurant l’inter-opérabilité en environnement hétérogène.

5. Le point de vue de la technologie : il expose les contraintes technologiquesimposées par les mécanismes d’ingénierie à une infrastructure matérielleou logicielle spécifique.

Nous ne détaillons, dans les paragraphes suivants, que les points de vue destraitements et d’ingénierie, car c’est en eux qu’apparaissent des élémentsimportants auxquels nous ferons référence dans ce document.

1.1.2.1. Le point de vue des traitements

Concepts de base

Une application est un ensemble d’objets, appelés objets de traitement, quiencapsulent un état interne et des données. Un objet peut modifier son étatinterne en réalisant des traitements sur ses données. Une opération est un pointd’accès à un traitement exécutable par un objet à la demande explicite de sonenvironnement (c’est une méthode dans la terminologie objet). Les terminaisonsdes opérations sont nommées.

Les opérations d’un objet sont regroupées dans des interfaces qui constituentl’unité de désignation et d’accès à un objet. Toute interaction avec un objet a lieu àune interface. On distingue deux types d’invocations, en fonction du modèled’opération appelé. L’appel d’une opération sans terminaison est appelé uneannonce, celui d’une opération avec terminaison est appelé interrogation. L’objetinitiateur de l’invocation est appelé client, son destinataire est le serveur.



Seules les interfaces de service (décrivant les opérations offertes par un objet)sont explicitement décrites; un objet peut en posséder plusieurs, permettant ainside ne rendre accessibles que des sous ensembles d’opérations qu’il peut traiter. Unobjet A ne peut invoquer une opération sur un objet B que s’il dispose d’uneinterface de B décrivant cette opération.

Typage des interfaces

Les interfaces sont typées. Lorsqu’un client demande une interface d’un certaintype, il peut obtenir la référence d’une interface non pas identique mais conforme àcelle qu’il a demandée. La conformité assure la transparence à la substitution : leclient ne se rend pas compte que l’interface qu’il manipule n’est pas identique àcelle qu’il a demandée. La conformité permet de vérifier la faisabilité des liaisonsentre deux interfaces.

Une interface de type I2 est conforme à celle de type I1 si I1 est un sous type deI2; c’est-à-dire si I2 possède une opération conforme à chaque opération de I1 (ellepeut posséder d’autres opérations). Une opération Op2 est conforme à Op1 si elle ale même nombre d’arguments, que le type de ces arguments est un sous-type deceux de Op1, qu’elle possède au plus le même nombre de terminaisons, et que leurtype est une restriction de ceux de Op1.

Qualité de Service

Certaines propriétés de QoS (en particulier les propriétés temporelles) qui ontété définies dans le modèle d’entreprise concernent directement le modèle detraitement, elles imposent des contraintes sur les événements qui ont lieu auxinterfaces des objets (un délai entre l’initiation d’une invocation et sa terminaisonpar exemple).

Propriétés des opérations

Le modèle de traitement ODP associe aux opérations des propriétés dites“transactionnelles”, qui permettent d’exprimer les propriétés requises par lesdifférents niveaux de cohérence. Ces propriétés concernent la visibilité(accessibilité des objets), la cohérence (invariants à satisfaire), la recouvrabilité(reprise sur erreurs), la permanence (irrévocabilité d’une transaction réussie) et ladépendance (résistance aux erreurs d’autres transactions) des opérations.

L’encapsulation est totalement respectée par le modèle, qui ne fait aucunehypothèse sur le nombre d’activités concurrentes à l’intérieur d’un objet. Lespropriétés des objets sont uniquement appliquées aux opérations et non auxactivités.

Liaisons

Une liaison est l’abstraction des mécanismes mis en oeuvre pour assurerl’interaction entre deux objets lors d’une invocation d’opération. Elle doit assurerdeux transparences essentielles, la transparence à la localisation, qui assure qu’unobjet n’a pas à savoir où se situe l’objet qu’il invoque, et la transparence d’accès, qui



garantit que l’invocation d’une opération se fera de façon identique que l’objetinvoqué soit distant ou local. D’autres transparences existent : transparences degroupe, à la duplication, à la migration, aux pannes, transactionnelles...

On peut requérir des garanties de QoS d’une liaison, concernant par exempleles durées des communications entre un client et un serveur, puisque du point devue du client ces durées sont inclues dans le temps d’exécution de l’invocation. Acet effet, le modèle ODP propose des créations explicites de liaisons offrant desgaranties de QoS, ces créations retournant une interface de contrôle de la liaisoncréée, permettant notamment de la détruire ou de modifier ses paramètres.

1.1.2.2. Le point de vue d’ingénierie

On peut considérer le point de vue d’ingénierie comme une description desrègles qui président à la mise en oeuvre des objets et des liaisons du modèle detraitement.

Mise en oeuvre des objets du modèle de traitement

La mise en oeuvre puis l’exécution des objets du modèle de traitements setraduisent par l’utilisation de ressources et la génération d’activités dans lesystème. L’unité d’encapsulation de l’exécution et des ressources est la capsule.L’infrastructure support doit offrir un service de gestion de capsules. A l’intérieurd’une capsule se trouvent des objets d’ingénierie de base, qui peuvent êtreregroupés en grappes (clusters). Une grappe est l’unitéd’activation/désactivation/migration d’objets d’ingénierie de base.

Chaque noeud (unité physique localisée dans l’espace possédant des fonctionsde calcul, mémorisation et communication) possède un noyau pour coordonner lesfonctions du noeud afin de les rendre utilisables par les objets d’ingénierie.

Mise en oeuvre des liaisons du modèle de traitement

La mise en oeuvre d’une liaison est appelée un canal, qui est un ensembled’objets qui assurent la transparence à la distribution (accès et localisation) etgèrent le protocole de communication.

La gestion de transparences additionnelles ou des garanties de QoS est obtenueen adaptant les gestions de configurations (choix de noeuds, de protocoles decommunication...) et la gestion des ressources (dimensionnement des tampons,ordonnancement des tâches...).

1.1.3. Les fonctions ODP

La norme ODP identifie un ensemble de fonctions nécessaires à la constructiond’un système ODP. Elles concernent

• la gestion des différentes entités du système, qu’elles soient locales à unnoeud ou réparties (threads, datations, canaux, objets, référencesd’interfaces...);



• les dépôts de données relatives aux objets et à leurs interfaces;

• le contrôle d’accès aux objets, l’écoute et l’analyse des événements liés à lasécurité se produisant dans le système.

1.1.4. Les bienfaits du modèle

Le modèle de référence RM-ODP a permis de clarifier le concept d’architecturede systèmes informatiques répartis. Il a en particulier l’avantage de ne pasprésenter un système uniquement par son interface mais par une définitioncomplète et précise de toutes les entités qui le constituent, leurs propriétés et leursinteractions possibles. D’autre part l’identification des points de vue permet lamodélisation des différents aspects concernés par la notion d’architecture desystèmes répartis.

Le modèle ne définit pas un seul système, mais une architecture généralepermettant de décrire/construire un ensemble de systèmes possédant un sous-ensemble des fonctionnalités de la norme. Par exemple, un système pourra ne pasoffrir toutes les transparences qui y sont mentionnées. Un système est ditconforme RM-ODP (RM-ODP compliant) s’il possède les caractéristiques de basedu modèle de référence, et que ses structures répondent aux exigences de lanorme.

Pour notre étude, nous nous intéressons principalement aux points de vue dutraitement et de l’ingénierie, car ce sont les visions du système les plusimportantes pour la description d’un système temps-réel. Nous examinerons aussinotre système sous l’angle technologique afin de préciser l’implémentation quenous envisageons.

1.2. Réalisation d’un plate-forme ODP avec garantie de service

Nous présentons maintenant la façon dont nous souhaitons traiter lesdifférents aspects de la réalisation d’une plate-forme ODP avec garantie de service.Ceux-ci couvrent la gestion de la QoS, la réalisation du contrôle du système et leschoix technologiques qui nous semblent les mieux appropriés.

1.2.1. Gestion de la QoS

La Qualité de Service (Quality of Service, QoS) décrit les propriétés nonfonctionnelles d’un service, en terme de performances et de valeur. Elle peutcouvrir différents aspects du service, en voici une liste non exhaustive :

• Propriétés temporelles : exprimées en délais, échéances, gigues, ellespeuvent concerner des événements individuellement (e.g. fréquence d’unévénement) ou en groupe (e.g. intervalle minimum entre deux événementsdifférents). On peut en demander une garantie statistique ou déterministe.

• Volumes : exprimées en débit, bande passante, ou nombre d’octets, enstatistiques ou absolus.



• Criticalité : utilisée pour gérer les situations de surcharge, elle prend engénéral la forme d’une priorité, qui permet de décider quel service doit êtredégradé pour que les plus importants puissent s’exécuter correctement.

• Coût : en unité monétaire, il peut être lié à une transaction ou à un accès àun service.

• Sûreté de fonctionnement : mesure du risque de pannes, souvent expriméeen temps moyen avant une panne.

• Sécurité : exprimée en probabilité d’attaques réussies contre l’intégrité ou laconfidentialité du système.

• Qualité de présentation : mesure de la qualité des données produites par unservice, particulièrement utile dans le domaine des applications multimédia(e.g. résolution/nombre de couleurs d’une image, ou nombre de bitsd’échantillonnage d’une source sonore).

Dans le cadre de notre étude, nous nous intéresserons uniquement auxpropriétés temporelles et celles concernant les volumes. Nous traiterons lescontraintes de façon déterministe, c’est-à-dire que soit un service s’engage a priorià toujours respecter une contrainte, soit elle est refusée, l’utilisateur du serviceayant alors le choix entre bénéficier du service sans garantie et abandonner cetteinteraction.

Lorsqu’un service garantit les besoins d’un client, il est en droit de poser desconditions à ce client. Par exemple un service de conversion de couleur d’uneanimation vidéo, si elle garantit une fréquence de 10 images par secondes, espèreévidement en entrée une fréquence au moins égale à cette valeur, et peut aussiimposer un maximum à cette fréquence afin de ne pas surcharger ses ressourcesinutilement. La garantie est donc le fruit d’un contrat entre un client et un service,qui définit clairement leurs droits (ce qu’ils attendent l’un de l’autre) et leursdevoirs (ce qu’ils doivent à l’autre), mais aussi les pénalités qu’ils encourent si lecontrat n’est pas respecté. Plus généralement on peut considérer qu’un servicefournit une fonctionnalité à son environnement, avec une certaine QoS (la QoSofferte), à la condition que l’environnement respecte certaines contraintes, qui sontelles-mêmes des spécifications de QoS. L’environnement comprend l’infrastructuredu système et l’ensemble des objets qu’il contient.

En plus des transparences classiques offertes par les systèmes répartis (accès,localisation...), nous souhaitons offrir la transparence à la QoS. L’utilisateur dusystème, lorsqu’il spécifie ces contraintes de QoS, ne sait pas quels mécanismesvont être mis en jeu pour les réaliser.

1.2.1.1. Du point de vue des traitements : Spécification de QoS

Pour pouvoir écrire des contraintes de QoS, il est nécessaire de disposer d’unlangage permettant d’exprimer des relations complexes entre des événements.Pour ce qui concerne les comportements temporels, on trouve des langages tel RTL[JAH86] qui répondent à cette attente. PSDL [BER88] est aussi un langage



permettant d’exprimer les contraintes temporelles d’un système, mais il est moinscomplet et n’offre pas de méthode de vérification des contraintes. Un autrelangage, nommé QL, permettant d’exprimer une qualité de service, estactuellement à l’étude [STE93]. Il permet de décrire des contraintes sous formedéclarative en considérant les événements relatifs aux émissions et réceptions desrequêtes et réponses aux interfaces impliquées dans une invocation.

Une déclaration de QoS peut concerner n’importe quel objet du système. Dansnotre modèle, les objets sont représentés par leurs interfaces, c’est donc dans cesinterfaces que seront décrites la QoS des services. Une déclaration de QoSapparaît comme un ensemble de clauses de QoS, chacune comprenant deuxaspects :

• Les besoins de l’objet (QoS requise), c’est-à-dire les propriétés qu’il attendde son environnement pour pouvoir remplir sa mission correctement.

• Les propriétés qu’un utilisateur peut attendre de lui (QoS offerte). Cespropriétés ne seront effectivement vérifiées que si le l’environnementrespecte ses besoins.

Le langage de description des types d’interfaces est étendu pour inclure lescontraintes de QoS (offerte et requise). Cette description ne fait pas desuppositions sur les mécanismes mis en jeu pour les réaliser. Ceci rend possiblesdifférentes implantations à partir d’une même spécification du point de vue destraitements. On obtient ainsi la transparence à la QoS, assurant une forme deportabilité des applications temps-réel.

Pour pouvoir décrire ces contraintes, il est nécessaire de faire apparaître dansles interfaces non seulement les opérations offertes, mais aussi les opérationsexternes utilisées. Si les serveurs implantant le service d’une interface de type I1ont besoin de l’opération Op2 d’une autre interface (qu’ils ne connaissent pasencore), il faut faire apparaître la signature de cette opération dans I1. Il seraalors possible, dans les clauses de QoS, de faire référence aux événements liés àl’invocation de cette opération.

Puisque nous avons étendu, par rapport au modèle ODP classique, ladescription des interfaces, il nous faut maintenant redéfinir la notion deconformité. Tout d’abord voici un moyen de comparer deux clauses de QoS : Unecontrainte A est plus forte qu’une contrainte B si la vérification de A implique lavérification de B. Dans ce cas, on peut aussi dire que B est plus faible que A. Parexemple, si une clause A énonce qu’un événement doit avoir une fréquencesupérieure à 10Hz, et qu’une clause B fixe 20Hz pour le même paramètre, la clauseB est plus forte que la A.

Le modèle spécifie qu’une interface de type I2 est conforme à celle de type I1 siI1 est un sous-type de I2. Nous précisons maintenant cette notion de sous-typage :en plus des exigences classiques, il faut que les clauses de QoS requises de T1soient plus faibles que celles de I2, et que les clauses de QoS offerte dans I1 soient



plus fortes que celle de I2. Deux types de vérifications peuvent être faits sur cescontraintes, qui correspondent à deux moments de la vie d’une interface :

• Statiquement, au moment de la déclaration de l’interface, certaines clausesde QoS peuvent faire l’objet de vérifications de cohérence. Cela permetd’éviter l’introduction dans le système de clauses incompatibles, quigénéreront des erreurs systématiques. Cette vérification a aussi la chargede détecter les clauses redondantes : lorsque deux clauses expriment unecontrainte de même type, l’une étant incluse dans l’autre, il faudrait neconserver que la contrainte la plus forte. Toutefois les contraintesredondantes peuvent amener à des problèmes de cohérence, elles sont doncinterdites dans notre modèle.

• Dynamiquement, lors de la connexion de deux interfaces (par exemple surune invocation) possédant des contraintes de QoS, il faut vérifier que leurscontraintes sont compatibles.

1.2.1.2. Aspect d’ingénierie : traitement des contraintes de QoS

Le modèle d’ingénierie est responsable de la mise en oeuvre des contraintes deQoS exprimées dans le modèle de traitement. Ce traitement comprend deuxaspects : l’interprétation des contraintes du modèle de traitement, et la mise enplace de services pour les gérer.

Interprétation des contraintes

Les contraintes du modèle de traitement font référence à des abstractions quidoivent être expliquées au niveau du modèle d’ingénierie. Elles contiennent desinformations qui doivent être extraites et transmises aux gestionnaires deressources concernés. Par exemple, les contraintes de fréquences d’un service vontaffecter l’ordonnancement de la tâche qui l’exécute. L’extraction de cesinformations doit être faite de façon automatique. Pour cela il faut identifier leseffets de chaque type de clause de QoS sur la gestion des ressources du modèled’ingénierie.

Les contraintes de QoS peuvent impliquer des traitements complexes etcombinés de plusieurs gestionnaires de ressources. Par exemple, une contrainted’échéance de bout en bout sur l’exécution d’un service situé sur un site autre quecelui de son client entraîne une gestion d’ordonnancement réparti, avecréservation de ressources de communication. La traduction automatique de tellescontraintes en paramètres de gestion de ressources reste un sujet d’étude.

La surveillance de la QoS nécessite la présence d’objets d’observation, desmoniteurs [RAJ92][BEJ96], qui captent les événements pertinents de l’exécutionet comparent leurs caractéristiques (temporelles, en valeur, en volume...) aveccelles réclamées par la QoS. En cas de non-conformité, les capteurs doivent avertirle système ou les applications des erreurs survenues. Un moniteur a uncomportement réactif, il prend en entrée les événements produits à une ouplusieurs interfaces, effectue un contrôle sur des propriétés qui leur sont associées,et en conséquence émet éventuellement en sortie des événements de signalisation.



Il est envisageable de générer automatiquement le code synchrone de cesmoniteurs à partir des spécifications de QoS du modèle de traitements. Il estpossible que l’exécution de ces moniteurs requière elle aussi une certaine QoS,simple, sur laquelle on ne pourra bien sûr plus faire de supervision.

Services de gestion de QoS

Le système d’exploitation doit disposer de moyens permettant d’établir et devérifier le respect des contraintes en cours d’exécution. Ces moyens prennentdifférentes formes :

• Des fonctions de manipulation des interfaces permettant de vérifier lacorrespondance entre deux déclarations de QoS, utilisées lors de larecherche d’une interface par le service de courtage, ou au moment de laconnexion de deux interfaces.

• Des fonctions de contrôle dynamique de faisabilité des contraintes,permettant de rejeter a priori les contrats de QoS qui ne sont pasréalisables étant donné l’état de l’environnement dans lequel ils s’exécutent.

• Des fonctions d’établissement de QoS, qui permettent de lier des interfacesentre elles avec une certaine QoS. Cette connexion produit une interface decontrôle pour gérer cette connexion, et des outils de surveillance : leséchanges entre ces interfaces doivent être observés et mesurés afin devérifier que la QoS annoncée est bien respectée. Lorsqu’une violation deQoS est détectée, le système de surveillance a la charge d’en avertir lesobjets concernés.

modèle detraitements

modèled’ingénierie

interpréteur-distributeur dedesc. de QoS

...ordon−nanceur

gest.mém.

gest.comm.

DESC. INTERFACE

// interf. op. de serviceOp1(...)Op2(...)

// interf. op. clientOpExterne(...)OpExt2(...)

// desc. QoSQoSrequise : ...QoSofferte : ...

moniteur

servicesde gestionde QoS

Correspondance entre la QoS déclarée dans la modèle de traitementset sa gestion dans le modèle d’ingénierie



1.2.2. Gestion du contrôle

Nous faisons appel à la notion d’objets réactifs pour effectuer lasynchronisation et le contrôle des événements du système. Un objet réactif est unobjet qui réagit à des modifications de son environnement, qu’il détecte à l’aide designaux entrants, en produisant des signaux sortants. Ces objets sont programmésà l’aide de langages synchrones. Ces langages reposent sur l’hypothèse synchrone,qui stipule que les communications à l’intérieur d’un objet synchrone sontinstantanées et que ses réactions ont une durée nulle.

1.2.2.1. Du point de vue des traitements : l’approche synchrone

Dans les années 80 [BER83][HAR85] est apparue la notion de programmationsynchrone, qui s’appuie sur quelques principes simples, et permet d’écrireélégamment des applications réactives sûres. Le principe de base est de considérerqu’un programme synchrone stimulé produit ses sorties instantanément. Toutesles opérations à l’intérieur de la réaction (calculs et communications) ont donc unedurée nulle.

Dans le modèle ODP, du point de vue des traitements, ces événementscorrespondent à des invocations d’interfaces. Les événements d’entrée peuvent êtredes réceptions d’invocation ou des réponses à une invocation, en sortie on produitdes demandes d’invocation ou des réponses à des invocations. A l’intérieur d’unobjet réactif, les communications sont instantanées, mais toute interaction externeavec un autre objet, qu’il soit réactif ou non, prend du temps. Pour avoir desgaranties sur ces communications, on établit une liaison entre les deux objets. Uneapplication temps-réel peut être composée de plusieurs objets réactifs, chacuncontrôlant un ensemble d’objets non-réactifs.

Du point de vue des traitements, l’hypothèse de synchronisme fournit uneabstraction simple et riche pour effectuer la partie contrôle des applications temps-réel. Elle permet au programmeur de réaliser une synchronisation déterministe, etdonc sûre, ce qui est un avantage important par rapport au modèle asynchrone.

Faiblesses du modèle asynchrone

L’évaluation des méthodes de programmation généralement utilisées pour lessystèmes temps-réel [BEN91] est décevante. Examinons en quelques unes parmiles plus courantes :

1− La connexion de programmes classiques communiquant par appels système.C’est le plus fréquemment utilisé. Ces applications sont difficiles à étudieret à maintenir, et il est pratiquement impossible de faire une analyseautomatique de comportement. De plus, les appels systèmes ne sont pastoujours déterministes, ce qui accroît l’incertitude sur l’exécution de cesapplications.

2− Les automates d’états finis. Ils sont déterministes, performants, offrent despossibilités d’analyse automatique, mais ne supportent pas directement la



conception hiérarchique modulaire et la concurrence. Ils sont d’autre partdifficiles à comprendre et à maintenir.

3− Les réseaux de Pétri. Ils sont surtout utilisables pour de petitesapplications. Ils supportent la concurrence mais pas de modularité ni dedéterminisme.

4− Les langages de programmation concurrents classiques comme ADA,OCCAM. Ils permettent la programmation concurrente, la modularité, maissont non déterministes. Il y a peu de possibilités d’analyse automatique, enraison du nombre trop important d’états.

Les langages de programmation non synchrones ne permettent pas de garantirque l’exécution de “wait(3); wait(5)” est exactement identique à “wait(8)”. En effet,il n’est pas possible de connaître l’intervalle de temps séparant deux instructionsséquentielles, car la sémantique de l’opérateur de séquencement “;” autorise unintervalle de temps quelconque entre les deux “wait”.

L’instantanéité

Les langages synchrones donnent une sémantique précise à la séquence“wait(3); wait(5)”, qui est exactement équivalente à celle de “wait(8)”. Une réactionest instantanée, toutes les instructions qui la composent ont une durée nulle, ycompris le séquencement “;”. Seules les opérations d’attente d’événementpermettent l’écoulement du temps, puisqu’elles arrêtent l’exécution du programmesynchrone, marquant ainsi la fin de la réaction. L’instantanéité n’est pas unenotion neuve pour les physiciens, puisqu’elle est par exemple utilisée enélectronique, où l’on considère, lors de la modélisation d’un circuit, que lechangement de valeur d’un signal est instantanément propagé sur l’ensemble ducircuit.

L’instantanéité des réactions garantit les propriétés suivantes sur l’exécutiond’un module synchrone :

• Les sorties sont présentes dans le même instant que les entrées qui les ontproduites.

• Une réaction est atomique : elle est soit exécutée totalement, soit nonexécutée.

• On ne peut avoir aucun résultat partiel de la réaction, la totalité de sesrésultats est disponible au même moment.

• Les communications entre des blocs d’exécution parallèles à l’intérieurd’une réaction ont une durée nulle.

Bien sûr, cette vision est utopique, il n’existe aucune machine infinimentrapide, capable d’exécuter du code instantanément, mais on peut considérer quel’instantanéité est vérifiée si le monde extérieur réagit plus lentement que le



programme réactif, ce qui implique qu’il n’a pas le temps d’interagir avec leprogramme pendant l’exécution d’une réaction. Ceci est souvent vrai, le code desprogrammes réactifs étant suffisamment rapide pour qu’un environnement quivient de lancer une réaction n’ait pas le temps ni de produire un nouvelévénement, ni de détecter que les sorties de la réaction ne sont pas encoreproduites, avant que la réaction ne soit terminée.

Réactivité, temps multiforme discret

Un module réactif n’est stimulé que si un événement lui est présenté en entrée,le temps absolu n’est pas directement perçu dans un programme synchrone, àmoins de connecter un signal d’entrée à un générateur périodique, un signal “MS”émis toutes les millisecondes par exemple. On dispose alors de la notion de tempsphysique dans un programme synchrone, on pourra écrire “attendre 10 MS; ”, cequi a pour effet d’attendre la dixième occurrence du signal “MS”. Mais il est aussipossible d’imaginer n’importe quelle forme de temps; le mètre, par exemple, peutêtre une unité de temps valide, et un signal “METRE” qui lui correspondrapermettra d’écrire “attendre 100 METRE; tourner_a_droite(); ”. Laprogrammation synchrone offre donc ce que l’on appelle un temps multiformediscret.

Déterminisme

Les programmes synchrones sont traduits, par la phase de compilation, en unautomate fini qui résout une fois pour toutes le parallélisme du programmeoriginel. Toutes les communications entre les blocs d’exécution parallèles sontrésolues à la compilation, certaines n’engendrant aucun code, elles se manifestentsous la forme d’états et de transitions. Le code de l’automate est purementséquentiel. Ceci a pour effet de rendre totalement déterministe l’exécution duprogramme, toutes les exécutions de l’automate, avec le même événementd’entrée, donneront exactement les mêmes résultats.

Ce déterminisme permet la vérification automatique des programmes, ce quin’est pas possible dans le cas des langages asynchrones. Il est facile de vérifierqu’un programme ne va pas boucler infiniment, ou ne possède aucun état “puits”,duquel il sera impossible de sortir, ou plus simplement on peut prouver quel étatde sortie on obtiendra en stimulant l’automate à partir d’un état donné. Cettevérification peut aussi être faite de façon mathématique, la sémantique deslangages synchrones pouvant être décrites avec des règles de réécritureconditionnelles [BOU91] qui, par dérivations, permettent de prouver qu’unprogramme a une solution, et donnent une description précise du comportement del’exécution.

Les langages

Les langages synchrones se sont multipliés ces dernières années, certains neprésentent pas toutes les particularités décrites ci-dessus. Il existe deux formes deprogrammation synchrone [BEN91] :



• Orienté états (state based formalism) : le programme décrit les états quepeut prendre l’automate, et les événements qui peuvent faire changerd’état. On peut facilement le représenter graphiquement par un diagrammeà transition d’états, où les flèches sont labellées par les communicationsgénérées. Les STATECHARTS [HAR87] utilisent directement ce formalisme,ESTEREL [BOU91] et CSML [CLA91] se basent aux aussi sur ces notionsd’états, mais de manière moins évidente pour le programmeur. Ce type deprogrammation, le plus naturel, est particulièrement adapté auxapplications où le flot de contrôle prévaut.

• Système récurrent à horloge multiple (Multiple Clock Recurrent Systems,MCRS) : ce formalisme est plus adapté aux applications guidées par desflots de données. Il permet d’exprimer par des équations les valeurs dechaque donnée (dont la suite de valeur définie une horloge) en fonction desvaleurs passées et présentes de ces données. LUSTRE [HAL91] et SIGNAL[GUE91] sont des langages utilisant ce formalisme.

Ces langages sont traduits par le compilateur en un autre langage. Si cedernier est orienté objets, nous qualifierons alors le code généré d’objet synchrone.Toutefois il est possible d’accéder à cet objet comme n’importe quel autre, sansconnaissance de son synchronisme.

1.2.2.2. Aspect d’ingénierie : exécution des objets de contrôle

Le point de vue des traitements offre une vision idéale des réactions des objetssynchrones en supposant qu’elles ont une durée nulle, mais cette propriété n’estplus vraie au niveau ingénierie : c’est à ce niveau qu’il va falloir gérer les réactionspour offrir une transparence à la durée.

L’automate généré ne possédant pas d’activité propre, son exécution doit êtrefaite par un programme qui positionnera les signaux d’entrée, décidera dedéclencher une transition et collectera les signaux de sortie en fin de transition.L’environnement qui remplit ces fonctions est appelé machine d’exécutionsynchrone.

Son rôle n’est pas uniquement celui d’une interface de présentation/réceptiondes signaux, elle doit aussi préserver la sémantique du synchronisme dans unenvironnement d’exécution asynchrone, ce qui consiste à :

• Garantir l’atomicité des transitions. Les effets d’une transition sur sonenvironnement sont uniquement produits par l’émission de signaux desortie. Une transition ne peut pas se produire partiellement, c’est à dire quesoit tous les signaux de sortie sont émis, soit aucun ne l’est. La machined’exécution doit donc différer l’émission effective des signaux de sortiejusqu’à la fin de la transition. Si pour une raison quelconque la transitionne se termine pas (plantage, interruption volontaire...) aucun des signauxde sortie ne sera émis.



• Garantir l’instantanéité. Le monde synchrone suppose qu’une transition estinstantanée, et donc qu’aucun événement ne peut se produire pendantqu’elle s’exécute. Si cela venait à se réaliser, la machine d’exécution doitprendre une décision, elle peut par exemple générer une erreur, ou bienmettre en attente l’événement afin que la monde synchrone ne le perçoivequ’à la fin de la transition en cours, ou encore annuler la transition en courset la faire redémarrer avec le nouvel événement.

D’autre part, c’est la machine d’exécution qui décide de démarrer unetransition. Elle peut disposer de différentes politiques pour prendre cette décision :démarrer une transition dès qu’un signal d’entrée est présent, ou bien lancer destransitions périodiquement...

Les trois rôles fondamentaux de la machine d’exécution sont donc l’interfaçagedes signaux en entrée et en sortie, la préservation de la sémantique synchronedans un monde asynchrone, et la gestion des transitions.

1.2.2.3. Aspect technologique : choix du langage

Nous avons choisi le langage synchrone ESTEREL [BEY92] pour écrire les objetsréactifs de notre système. Les raisons de notre choix sont la clarté de sa syntaxe,des études qui ont été faites concernant sa sémantique et des outils dedéveloppement qui lui sont associés. Une description d’Esterel est présentée enannexe.

1.2.3. Les micro noyaux : Evolutifs et modulaires

Dans les années 80 est apparue une nouvelle approche pour le développementdes systèmes d’exploitation, qui prône la distinction entre la gestion de base dusystème réalisé par un micro noyau et le système avec son interface utilisateur,que l’on appelle sous-système, développé au-dessus du micro noyau. Ce typed’architecture est particulièrement intéressant pour les développeurs de systèmeset plates-formes qui peuvent s’appuyer sur des mécanismes de base, que nousallons détailler, pour construire un environnement évolutif, portable et modulaire.

Le micro noyau fournit une interface générique qui permet de faire abstractiondes particularités de la machine sous-jacente, ce qui le rend attractif pour ledéveloppement de systèmes répartis hétérogènes. Inversement, il permet deconstruire différents sous-systèmes en se basant sur une interface commune, sansavoir à réécrire le système entier. Les principales fonctionnalités qu’il doit assurerconcernent :

1. la gestion du processeur, c’est-à-dire la gestion de l’état des threads et deleur ordonnancement, ainsi que la prise en compte des interruptions;

2. la gestion de la mémoire, la structure des espaces d’adressage;

3. les outils de communication et synchronisation entre tâches, qui peuvent sesituer sur des machines de natures différentes;



4. un système d’identification des différents éléments du système au moyen declef ou noms.

Le sous-système est généralement construit de façon modulaire, en unensemble de serveurs fournissant chacun une partie des fonctionnalités d’unsystème d’exploitation : gestion des systèmes de fichiers, des périphériques, destâches utilisateurs, des communications utilisateurs...

Cette structure est clairement plus évolutive que celle des systèmesmonolithiques, puisque ici chaque serveur est développé indépendamment, avecune interface bien définie pour coopérer avec le reste du système, rendant ainsiplus facile sa mise à jour ou son remplacement. Cela permet aussi de disposer desystèmes ‘partiels’, ne disposant pas de tous les serveurs du sous-système, ce quiévite de surcharger une machine avec des serveurs qui ne sont pas utilisés. Cepoint est particulièrement important pour les systèmes temps-réel, qui n’ont biensouvent besoin que d’un contexte minimum d’exécution. On peut ainsi imaginerl’environnement distribué présenté dans la figure ci-dessous.

Objets decontrôle de

périphérique

Réseau

Interface noyau

micro noyau

site Β

Interface noyau

micro noyau

objetssous-système

Interface utilisateur

Objetsapplicatifs

site C

Interface noyau

micro noyau

objetssous-système

Interface utilisateur

Objetsapplicatifs

site A

Périphérique

Système distribué à base de micro noyaux

Nous utiliserons le système CHORUS [CHO92] pour réaliser nos implantations.Une présentation rapide de ce noyau est fournie en annexe. Quelquesmodifications y ont été apportées afin qu’il offre toutes les caractéristiquesnécessaires à la construction de notre système :

• Séparation plus claire entre les mécanismes et la politique del’ordonnancement. Suite à cette modification, deux politiques ont étéimplantées, celle native de CHORUS, et une autre qui gère trois types dethreads, présentés ici par priorité décroissante : les threads “critiques”(ceux exécutant des tâches systèmes) sont gérés par priorités, les threads àcontraintes de temps sont gérées par EDF (Earliest Deadline First), et lesthreads sans contraintes sont ordonnés par priorité. Cette politique permetla cohabitation de threads temps-réel ou non, et prend en comptel’importance prioritaire de certains threads exécutant des fonctions du



système et dont les propriétés temporelles sont difficiles à mettre enévidence.

• Les inversions de priorités [MER89] peuvent se produire lors dessynchronisations (par sémaphores) ou communications (par IPC). Unmécanisme a été créé permettant de les borner dans le temps. Il a étéintégré à la gestion des sémaphores, et utilisé pour offrir un service decommunication temps-réel. Il est composé de deux éléments : (i) la sélectiond’une politique de gestion de file d’attente, qui ne pouvaient être ordonnéesqu’en FIFO dans la version de base de CHORUS, et qui peuvent maintenantl’être par priorités; (ii) la sélection optionnelle d’une politique de contrôled’inversion de priorités, une seule étant pour l’instant réalisée, celle del’héritage de priorité : si un thread bloque un thread plus prioritaire, ilprend sa priorité le temps de libérer le sémaphore.

• Réalisation de communications offrant des caractéristiques temps-réel(RTports) : il est possible d’associer aux portes de communications, à leurcréation, une politique de gestion de files, de contrôle d’inversion depriorité, et une politique de propagation de priorité, qui contrôle la façondont est automatiquement transmise au receveur la priorité de l’émetteur.Trois politiques sont actuellement disponibles : aucune propagation,héritage systématique de priorité, ou transmission explicite de priorité,c’est-à-dire que l’émetteur donne explicitement la priorité qui sera donnéeau récepteur.

• Un serveur de transport temps-réel, réalisant dans un acteur système leprotocole de transport sur le support physique, et offrant des garantiestemps-réel. Ce serveur se base actuellement sur un réseau FDDI. Suite àcette réalisation, une étude est actuellement menée pour mettre en place uncontrôle d’admission afin d’offrir des garanties de temps et de volume.

1.3. Comparaison avec d’autres travaux

Nous allons examiner maintenant quelques systèmes temps-réel, et lescomparer à notre approche afin d’en mettre en évidence les avantages. Pour cela,nous établissons une liste de points sur lesquels va porter notre attention, et quidéfinissent des caractéristiques à nos yeux essentielles d’un système d’exploitationtemps-réel :

1. Ouverture : propriété qui permet d’une part la portabilité du système, c’est-à-dire la possibilité de définir un composant indépendamment du sitesurlequel il va s’exécuter, et d’autre part son interconnexion avec descomposants situés sur d’autres noeuds.

2. Modularité du système : propriété structurelle qui assure l’indépendancedes composants du système, tout en autorisant leurs coopérations. Lamodularité permet la flexibilité, c’est-à-dire la possibilité de modifierpartiellement le système sans en perturber le fonctionnement global.



L’approche micro-noyau et la distinction mécanismes/politiques sont deséléments favorables à la modularité.

3. Modèle objets : le modèle ODP a montré l’intérêt de cette approche, enparticulier pour traiter les deux points précédents.

4. Langage de haut niveau pour la description de contraintes de QoScomplexes, des garanties devant être maintenues quelques soient lesconditions.

5. Outils de contrôle des applications : nous examinerons s’ils sont de basniveau (sémaphores, mutex...) ou plus évolués (graphe de dépendances,langages de description de comportement...)

6. Liaisons explicites : Une autre notion du modèle ODP fondamentale dansnotre approche, qui permet de qualifier et contrôler les interactions entredeux objets.

1.3.1. MARS

Le système MARS (MAintainable Real-time System) [KOP89] adresse lesproblèmes de résistances aux fautes dans un environnement temps réel distribué.

1. MARS n’est pas un système ouvert. Il nécessite une configuration matérielleprécise, qui est basée sur une structure de réseau en grappes interconnectées. Unegrappe est un ensemble de composants (sites) reliés par un “bus MARS”, qui est unréseau local (Ethernet) utilisant un protocole TDMA (Time Division MultipleAccess), qui permet de borner les temps d’accès grâce à une réservation statiqued’intervalles de temps. Deux grappes peuvent être interconnectées, à l’aide d’unecommunication SCSI entre deux composants de ces grappes. A l’intérieur d’unegrappe la connectivité est forte : l’horloge synchronisée possède une dérive bornéeà 4µs, il y a une gestion de la duplication pour gérer la tolérance aux fautes, etl’ordonnancement est réparti.

Le système suppose un environnement statique, dans lequel on connaîtl’ensemble des tâches qui vont s’exécuter avant le début d’exécution, ainsi queleurs caractères temporels. L’ordonnancement est fait avant l’exécution. Des listesdécrivant la chronologie des changements de contextes sont générées, un site peutavoir plusieurs listes, et des mécanismes de bascule d’une liste à une autre sontdisponibles. L’intérêt des listes est de prévoir plusieurs comportements dusystème. Par exemple, il est possible de préparer un ordonnancement au pire,incluant toutes les erreurs possibles, et un autre plus probable. Lors d’unfonctionnement normal, le second est utilisé, mais en cas d’erreur une alarme faitbasculer sur celui au pire. La seule interruption prise en compte est celle del’horloge. Les périphériques sont gérés par scrutations périodiques de cetteinterruption.

2. La structure du réseau Mars est modulaire, mais pas celle de sescomposants. Ils sont tous identiques, basés sur une plate-forme matérielle sur



laquelle se repose un noyau minimum : il traite l’ordonnancement et lesinterruptions, ainsi que la gestion de la mémoire, des communications et de ladate. Les composants matériels chargés du réseau et de la synchronisation sontcouplés, ils coopèrent pour l’écriture et la lecture automatique de tout messageenvoyé ou reçu. La synchronisation et l’ordonnancement des tâches étant effectuéavant l’exécution, la distinction interface/politique est plus simple à réaliser :l’interface est l’ensemble de liste d’ordonnancement construit par la phase deconception, les politiques pour les générer peuvent être facilement remplacés.

3. MARS ne possède pas de modèle objet. Il dispose d’un environnement dedéveloppement permettant de définir une application en utilisant les abstractionssuivantes : Une activité (tâche, communication) qui se déroule entre un stimulusexterne (capteur, commande de l’opérateur...) et la réponse (message, commanded’un périphérique...) constitue une transaction.

4. La description de contraintes de QoS se limite à l’expression, dans la phasede conception des applications, d’un temps maximum de réponse des transactions(MART). Le code est analysé, ce qui permet d’évaluer la durée maximum de latransaction (MAXT), l’ordonnancement permettra de vérifier que les autres tâchesn’ont pas besoin de plus MART-MAXT unités de temps entre la date T0 de débutde la transaction (connue) et T0+MART.

Pour respecter un ordonnancement, il faut que les tâches aient uncomportement déterministe. Pour cela certaines contraintes de programmationsont imposées : la récursion est interdite, et les structures itératives ont étéredéfinies, afin de pouvoir les borner soit en temps, soit en nombre d’itérations.MARS dispose d’un utilitaire évaluant pour chaque tâche son temps de calculmaximum, valeur qui sera utilisée dans l’ordonnancement.

5. MARS possède un outil de contrôle/synchronisation des applications : sonenvironnement de développement permet de définir des contraintes de précédencesentre les transactions, ces relations sont prises en compte par l’ordonnancement, leséquencement des transactions est donc décidé une fois pour toutes avantl’exécution.

6. L’ordonnancement prend en compte les communications entre les tâches,avec les contraintes associées aux transactions auxquelles elles appartiennent,permettant ainsi de synchroniser l’émission et la réception d’un message sur descomposants différents, et donc de déterminer à l’avance la durée entre l’émissionet la prise en compte d’un message. Cette garantie ne constitue qu’un sous-ensemble des fonctionnalités d’une liaison explicite.

1.3.2. ARTS

Le modèle de threads de ARTS a été repris dans RT-Mach [NAK90], la versiontemps-réel de Mach, à une exception près : les fonctions de valeurs ont étéabandonnées, car elles se sont révélées trops complexes à gérer.



1. ARTS [TOK89][TOK90] est un système ouvert, il ne nécessite pas une plate-forme matérielle particulière, et ne suppose pas de comportement particulier deson environnement.

2. Le noyau offre une séparation claire entre les mécanismes et les politiquesde ses composants : il est possible de modifier dynamiquement la politique del’ordonnanceur et des sémaphores. Les communications peuvent être faites surdifférents supports : sur une fibre Ethernet, mais aussi sur Token Ring, auquel casil est possible d’obtenir des garanties de bout en bout sur les communications.

3. Le modèle objets qu’il supporte, basé sur celui du C++, ne dispose pas de larichesse de la notion de type définie dans ODP : il n’y a pas de calcul dynamique deconformité de types, qui permet à un service de courtage de fournir à un client uneréférence d’un des serveurs réalisant un même type de service. La notion d’activitéapparaît dans les interfaces des services, mais le client n’a pas à s’en préoccuper,c’est au serveur qu’incombe le rôle de gérer la concurrence, qui est possible nonseulement à l’intérieur d’un objet mais aussi pour une même opération.

4. La description de contraintes de QoS est présente dans les interfaces, ellene permet de définir la périodicité, l’échéance et la criticalité des activités. Elleassocie une fonction permettant de définir la qualité d’un service en fonction de sadate de terminaison. Le rôle de l’ordonnanceur est alors de maximiser la valeur decette fonction.

5. ARTS n’offre pas de moyen d’exprimer facilement le contrôle desapplications. Les seuls outils de synchronisation qu’il offre (en plus de lacommunication par messages) sont les sémaphores et le masquage desinterruptions.

6. Le système n’offre pas de notion de liaison. Par contre il est une based’expérimentation de protocole de communications temps-réel, plusieurs ont étéimplantés : VMTP; le Real-Time Protocole (RTP), qui gère des messages auxquelson associe une priorité et une échéance, et détecte les dépassements avant leuroccurrence grâce à la durée d’exécution au pire associée à chaque opération dusystème; une extension temps-réel du Capacity-Based Session ReservationProtocol (CBSRP) a été expérimentée sur FDDI afin d’obtenir des communicationsprédicables.

1.3.3. SPRING

1. Les concepteurs du système SPRING [STA89] définissent eux-mêmes le typed’environnement pour lequel il est destiné : dynamique, vaste, complexe etévolutif. Toutefois l’hétérogénéité ne fait pas partie des préoccupations desconcepteurs, qui se sont basé sur une configuration matérielle précise pour définirleur architecture. SPRING s’exécute sur des machines multiprocesseur dont un estréservé à l’exécution des tâches système. Il ne gère pas les entrées/sorties, ellessont traitées par un sous-système indépendant.

2. L’ordonnancement est modulaire, il est divisé en quatre niveaux, enséparant les mécanismes des politiques. Le premier, le dispatcher, ne contient que



le mécanisme d’affectation d’une tâche à un processeur, le deuxième estl’ordonnanceur local, qui doit garantir les propriétés temporelles des tâches, letroisième est responsable de la délocalisation d’une tâche qui ne peut être garantielocalement, et le quatrième est un méta contrôleur veillant aux modifications del’environnement et modifiant des paramètres de l’ordonnancement. Il faut voirdans ce dernier niveau une des premières réalisations concernant les systèmesréflexifs, qui essayent de maintenir une représentation eux-mêmes et de leurenvironnement afin de capturer les modifications de l’un et de l’autre, et d’adapterle système en conséquence. La séparation entre le dispatcher et l’ordonnanceurlocal permet de continuer à exécuter les tâches garanties pendant le travail del’ordonnanceur local, qui peut être complexe et long.

3. Le système n’utilise pas la notion d’objet. Les entités manipulées parSPRING sont les tâches. Elles disposent d’un code réentrant, de données locales (àune instance) et globales (à toutes les instances).

4. Les contraintes de QoS associées aux tâches sont contenues dans undescripteur de tâches et un bloc de contrôle. Ils contiennent les caractéristiquestemporelles (temps d’exécution au pire, échéance, période), qualitatives (tâchetemps-réel ou non, criticalité), comportementales (préemptable, incrémentale,graphe de communications), et conditionnelles (graphe de précédences,précédences conditionnelles, et nombre et types de ressources requises). Lesconcepteurs de SPRING n’ont pas prévu de langage de haut niveau pour exprimerces contraintes, elles doivent donc être définies telles quelles, pour chaque tâche,par les développeurs. Il n’y a pas de distribution de contraintes élémentaires surdes tâches à partir d’une contrainte complexe. Toutefois les contraintes peuventtout de même concerner un groupe de tâches, puisqu’il est possible d’exprimer uneéchéance sur l’exécution d’un ensemble de tâches. Les garanties sont obtenues apriori pour les tâches critiques, qui doivent absolument avoir leurs contraintesrespectées. Les ressources sont pré-allouées pour ces tâches. Le coût d’une tellegarantie étant très important, il existe un autre type de garantie, pour les tâchesdites essentielles, dont le non-respect des contraintes entraîne une dégradation dusystème. Cette garantie est faite dynamiquement, elle ne tient compte que de lasituation courante de l’environnement, dont une modification de l’état peutentraîner des violations de contraintes de tâches essentielles.

5. SPRING ne possède pas d’outils de contrôle des applications, et ladocumentation ne fait pas état d’outils de synchronisation particuliers. L’exclusionmutuelle pour l’accès aux ressources et gérée par l’ordonnancement à l’aide de laliste des ressources requises des tâches définies dans leur descripteur, et le seuloutil de synchronisation des tâches est la communication par messages (qui peutêtre synchrone : l’émetteur et le récepteur sont bloqués jusqu’à ce que tous deuxsoient avertis de la bonne réception du message/accusé de réception). Il est tout demême possible d’associer un graphe de précédences aux tâches, qui sera pris encompte par l’ordonnancement pour garantir un contrôle “global” d’un groupe detâches, qui porte sur l’exécution entière des tâches. Ce qui fait défaut est donc lapossibilité d’exprimer et de contrôler l’occurrence des événements dans le système.



6. Il n’y a pas de notion de liaisons explicites. Les garanties que l’on peutobtenir sur les communications sont liées aux réservations de ressources decommunications.

1.3.4. MARUTI

1. MARUTI [LEV89][NIR90] est un système ouvert, permettant l’exécutiond’applications temps-réel distribuées. Le système ne fait pas de suppositions surl’environnement ni sur le matériel sur lequel il s’exécute.

2. L’approche objet adoptée par le système d’exploitation permet la modularitédu système, qui peut être divisée en deux couches, à la façon d’un micro-noyau : lapremière, le noyau, est l’ensemble minimum de serveurs nécessaire aufonctionnement d’un site. Il contient le gestionnaire d’interruption, l’ordonnanceur,le chargeur, un serveur de temps et le service de communication. La deuxièmecouche est constituée de serveurs superviseurs : l’allocateur, qui alloue lesressources en fonction des besoins des objets déclarés dans leur joint; l’objet lieur(binder) qui est non seulement responsable de la mise en place des canaux decommunications entre serveurs et clients, mais aussi de gérer les connexions avecles réplicas qui assurent la tolérance aux fautes; le serveur de noms; le serveur defichiers et l’interface utilisateur. Chaque objet peut être remplacé sans perturberle comportement des autres.

3. MARUTI dispose d’un modèle objets complet : Les applications et le systèmelui même sont composés d’un ensemble d’objets. Les objets qui offrent des services(les serveurs) doivent déclarer leur interface correspondante au serveur de noms.Un objet client souhaitant accéder à un service doit s’adresser au serveur de nomspour obtenir la référence d’un serveur. L’objet lieur fait ensuite une vérification deconformité entre les contraintes temporelles des deux entités à lier. La recherchese fait sur un serveur, et non sur un service, ce qui ne permet pas de chercher unserveur assurant le service désiré avec les contraintes spécifiées : le modèle nepossède pas la notion ODP de conformité de service.

4. La description des contraintes associées à l’exécution des objets figure dansleur joint. Le comportement d’un objet doit être entièrement connu avant sonexécution afin de permettre une réservation a priori de toutes les ressources et detous les serveurs dont il aura besoin. Un analyseur de code aide le programmeurdans cette tâche. Un programme peut être constitué de différents blocs detraitements ayant des contraintes particulières. L’analyseur de code en déduit ungraphe de blocs de traitements labellés par leurs contraintes de temps et deressources. C’est ce graphe qui est représenté dans le joint des objets. Cetteméthode oblige le programmeur à spécifier dans le code les contraintes sur sonexécution, elles sont donc fixées une fois pour toutes, quel que soitl’environnement.

5. Le contrôle des applications est réalisé par le calendrier des objets. Chacundéfinit les intervalles d’exécution des serveurs utilisés. Ce type de contrôle estuniquement statique, les contraintes sont soit acceptées soit rejetées a priori. Il



n’est pas possible de faire contrôle dynamique des exécutions, et donc d’y réaliserdes adaptations en fonction des modifications de l’environnement.

6. Maruti ne dispose pas des fonctionnalités des liaisons explicites telles quenous les entendons, il définit ses communications avec d’autres objets, ellesentraînent la réservation de ressources et un pré-ordonnancement qui permettentd’offrir des garanties, mais aucun mécanisme de contrôle de ces liaisons n’estdisponible.

1.3.5. Delta-4

1. Delta-4 [POW91] est un système ouvert, pouvant s’exécuter dans unenvironnement hétérogène. Le programmeur écrit ses programmesindépendamment des machines sur lesquelles ils vont s’exécuter, la phase decompilation traduisant les transparences en code explicite.

2. Delta-4 est modulaire. Deux versions sont disponibles, l’une mettant enavant la performance, l’autre l’ouverture et la tolérance aux fautes. Le système neréalise que les fonctionnalités hautes d’un système d’exploitation, il a besoin pours’exécuter d’un noyau, qui doit posséder des caractéristiques temps-réel.

3. Les applications sont constituées d’objets, qui se déclarent à un service decourtage qui permet de les rendre accessibles aux autres objets. L’interfaceexportée ne possède aucune spécification de QoS.

4. L’expression des contraintes de QoS est très limitée : Une échéance cible(target-line) est associée aux invocations, qui est utilisée par l’ordonnancementsuivant une politique best effort, conjointement avec la criticalité associée auxobjets, permettant de déterminer quelles contraintes doivent être prioritairementgaranties lors des situations de surcharge. Le système n’offre donc aucunegarantie sur les exécutions. La criticalité et l’échéance cible sont héritées par lesinvocations, ce qui permet un contrôle de bout en bout.

5. Le système ne propose aucun moyen d’effectuer un contrôle desapplications.

6. Il ne dispose pas de liaisons explicites, les communications sont de la formeRPC sans garantie temps-réel.

1.3.6. CHAOSarc

1. CHAOSarc [GOP89] est un système ouvert, qui se base sur l’interface d’unnoyau, CHAOSbase, pour assurer la portabilité de ses applications.

2. Le système est facilement modifiable, grâce d’un part à l’interface de sonnoyau, qui permet de changer les mécanismes et politiques de base sans avoir àréécrire le reste du système, et d’autre part à son approche objet qui définit desinterfaces pour tous les composants du système, autorisant une modification deleur comportement interne sans en altérer l’utilisation. Il utilise la notiond’attributs dans les interfaces des objets systèmes, qui sont une abstraction traitée



par ces objets pour sélectionner les politiques de gestion dont ils se servent. Cecipermet de ne pas modifier les interfaces lorsque l’on rajoute de nouvellespolitiques.

3. Le modèle objets utilisé par CHAOSarc s’appelle CHAOSmin, c’est unecouche du système qui est en charge de la gestion des classes, des objets et desinvocations. Cette couche permet de définir des objets passifs, qui sont exécutéspar le thread de l’appelant, ou actifs, possédant une activité propre. Les opérationsde création, destruction et invocation peuvent posséder des attributs non comprispar cette couche de base, elles sont alors redirigées vers la politique appropriée.

4. CHAOSarc est un ensemble de politiques traitant différents aspects del’exécution de tâches temps-réel. Il définit de nouveaux types d’attributs,permettant d’une part d’associer des contraintes temporelles aux invocations(périodicité, échéances, criticalité), et d’autre part d’ordonnancer les requêtessuivant une politique choisie. Une des politiques disponible est celle permettant lagestion d’invocations atomiques : l’invocation doit être exécutée avec succès, oubien faire l’objet d’une reprise avant ou arrière. Chaque objet possède sonordonnanceur, qui traite individuellement les invocations suivant leursparamètres.

5. Deux mécanismes de synchronisation sont proposés, les verrous et lespoints de synchronisation. Les premiers assurent une gestion des inversions depriorités, intégrant la préemption et le redémarrage des activités interrompues.CHAOSarc permet une adaptation réactive des échéances de composantsd’application : si le programmeur définit une échéance globale pour un traitement,et détermine les caractéristiques temporelles d’une part des traitements partielsqui le composent, et d’autre part des conditions supposées d’exécution(typiquement la fréquence d’arrivée des requêtes), le système peut détecter unemodification des conditions (e.g. la fréquence des requêtes qui augmente) etévaluer de nouvelles échéances pour les traitements partiels afin que l’échéanceglobale soit respectée. Ce type d’adaptation reste limité à un problème très précis.

6. Il n’y a pas de liaisons explicites dans CHAOSarc.

1.3.7. Bilan

Aucun des systèmes que nous avons présentés ne présente les caractéristiquesque nous attendons d’un système temps-réel.

Spring est un noyau de système d’exploitation, et à ce titre ne dispose pas desfonctionnalités de haut niveau que nous souhaitons réaliser : modèle objet,gestions des interfaces, liaisons explicites... D’autre part son architecture n’a pasla modularité que nous souhaitons.

Les autres systèmes présentés sont des systèmes d’exploitations complets. SeulMars ne dispose pas du modèle objet, c’est aussi le système le moins ouvert. Aucunne possède la richesse des interfaces que nous souhaitons, intégrant lesspécifications de QoS dans les interfaces des objets, client et serveurs, qui doiventêtre prises en compte au moment de la mise en relation de deux objets.



Aucun ne dispose de la notion de liaison explicite, possédant une spécificationde QoS et une interface de contrôle.

Les seules contraintes gérées par ces systèmes concernent le temps,contrairement à notre approche qui prend aussi en compte des contraintes devolume, et pourra être étendue à d’autres types sans modification de l’architecture,en ajoutant les règles de traduction de ces contraintes en paramètres deconfiguration/exécution du système.

1.4. Problématique et plan

Dans le but de réaliser un système d’exploitation intégrant l’ensemble desfonctionnalités présentées dans ce chapitre, il est nécessaire de procéder parétapes, permettant de valider une à une les options qui ont été prises. Le travail decette thèse porte sur l’une de ces étapes : l’utilisation de l’approche synchrone dansla programmation des systèmes d’exploitation.

1.4.1. Gestion synchrone des tâches

La réalisation d’un système d’exploitation temps-réel subit la même contrainteque celle des applications qu’il devra supporter : le code produit doit êtredéterministe et prouvable, afin d’avoir une connaissance complète et sûre de soncomportement. Tout système d’exploitation qui ne posséderait pas ces propriétésne pourra pas prétendre les garantir aux applications qu’il exécutera.

Nous avons montré comment la programmation synchrone nous permetd’atteindre ce double objectif de déterminisme et de démontrabilité. Noussuggérons donc de nous en servir pour réaliser des composants du systèmed’exploitation. Une approche modulaire permettra d’isoler les fonctions du systèmeafin d’encapsuler non seulement leur code et leur comportement, mais aussi leurspropriétés. Nous obtiendrons alors un système d’exploitation composé de modulesprouvables, dont on aura une parfaite maîtrise du comportement et des propriétés,et donc sur lesquels il sera facile de spécifier une qualité de service, en s’appuyantéventuellement sur celles d’autres composants. On peut par exemple imaginer quele module chargé de la communication propose un service de transfert de donnéesavec une qualité de service spécifiée en débit et en temps de réponse, ens’appuyant sur une spécification de QoS requise du module de gestion de mémoire(afin d’être sûr de disposer des tampons nécessaires) et de l’ordonnanceur (il fautavoir suffisamment de temps sur le processeur). Cette approche permetd’améliorer le QoS globale du système en modifiant/remplaçant un seul de cescomposants afin d’améliorer la QoS qu’il fournit. Tous les modules qui reposaientsur lui verront automatiquement leur QoS améliorée. La différence par rapport àun système classique, dans lequel l’amélioration d’un composant provoque aussi engénéral une amélioration globale, c’est que dans notre cas elle est clairementexprimée aux interfaces des modules : le gain est formalisable, il est possible d’enmesurer les conséquences sur le reste du système, chaque composant peutannoncer une nouvelle QoS fournie en fonction de cette modification.



Pour montrer la faisabilité de la composition de modules réactifs prouvablespour réaliser un système d’exploitation, cette thèse va présenter une implantationde la gestion des tâches du noyau conformément à cette approche. Cette gestion aen charge la prise en compte des événements pouvant affecter la vie des tâches, etla mise en oeuvre des mécanismes permettant de les exécuter. Cette fonction dusystème est de nature réactive, les modifications de l’état d’un thread ou del’allocation du processeur sont toujours faites en réaction à l’occurrence d’unévénement : requête d’une application, interruption horloge, terminaison d’untraitement d’interruption...

La mise en oeuvre d’un tel système suppose l’existence d’une machined’exécution synchrone. Le niveau d’exécution auquel nous nous plaçons pour laréaliser implique qu’elle ait la structure la plus légère possible, et lesfonctionnalités minimales : il ne s’agit pas de réécrire une gestion des tâches pouren exécuter une autre, auquel cas nous perdrions non seulement en performances,mais aussi en démontrabilité (cette machine d’exécution ne peut pas être écrite enprogrammation synchrone...). Nous devons développer une machine d’exécutionminimum, qui ne doit faire qu’une traduction des événements du système ensignaux ESTEREL, et une activation des réactions sur occurrence d’un événementpertinent.

L’ensemble de ces deux composants, le module réactif et sa machined’exécution, forme elle même une machine d’exécution native : elle peut servir àgérer directement des objets réactifs applicatifs. Il n’y a alors plus de traduction àfaire entre les événements produits par ces objets et l’interface de cette machined’exécution, ce sont directement des signaux ESTEREL, chaque objet synchrone estalors représenté par une tâche dans le noyau.

Machine d’exécutionminimum

tâcheclassique

objetréactif

traduction

Machined’exécution

native

Module degestion des

tâches

Machine d’exécutionminimum

Module degestion des

tâches

objetréactif

Utilisations du module de gestion synchrone des tâches

Toute réception de signal par un objet réactif peut provoquer l’ordonnancementde sa tâche, si elle est la plus prioritaire à cet instant. Lorsque la tâche prend le



processeur, elle exécute une réaction complète de l’objet réactif : prise en comptede tous les signaux présents à son interface d’entrée, transition de l’automate, etémission de signaux en sortie. Ces émissions seront de nouveaux événements àprendre en compte par l’ordonnancement, qui provoquera une nouvelle allocationdu processeur. Pour pouvoir prendre cette décision, il est nécessaire quel’ordonnanceur soit averti de l’occurrence de tous les signaux émis par les objetsréactifs, ainsi que leur destinataire. C’est cette information qui permettra deconstituer l’ensemble des objets “activables”.

Dans cette thèse nous n’intégrerons pas la fonction machine d’exécution nativeà nos réalisations de la gestion des tâches.

Pour nous aider dans la réalisation du module de gestion de tâches, nouspartirons d’un micro-noyau de système d’exploitation déjà existant, CHORUS. Nouseffectuerons une analyse de son code afin de comprendre comment sont réaliséesles communications et synchronisations à l’intérieur de ce micro-noyau. Nous enprésenterons une modélisation à l’aide d’un langage synchrone, ESTEREL, qui vanous permettre d’extraire la partie contrôle de la gestion de l’état du noyau dureste du code. Grâce aux formalismes des langages synchrones, nous serons alorsen possession d’un code déterministe sur lequel nous pourrons effectuer despreuves.

Nous décrirons alors la machine d’exécution minimum, qui permettra depréserver les propriétés du synchronisme et garantira la cohérence de l’exécutionde l’ensemble. Puis nous présenterons une implantation réelle de notre gestion destâches au-dessus du micro-noyau CHORUS.

Au cours de notre étude, nous nous efforcerons de ne pas traiter uniquement dela gestion du micro-noyau CHORUS, nous en ferons apparaître l’aspect commun àtoute réalisation de cette fonction. En particulier les politiques adoptées doiventêtre isolées du comportement générique, soit en disparaissant sous une interfacestandard qui sera utilisée sans a priori sur l’implémentation sous-jacente (e.g. lafonction d’élection de la tâche active), soit en se présentant sous la forme demodules annexes et interchangeables se greffant sur le modèle générique (e.g. unmodule de gestion d’échéances). Ceci permet d’instancier notre modèle en fonctiondes besoins ou contraintes de différents systèmes. Toutefois, puisqu’à terme notreobjectif est de remplacer la gestion de tâches de CHORUS, nous suivrons les choixde ses concepteurs, d’une part en implantant leurs politiques, et d’autre part enréalisant des modules conformes au comportement de CHORUS.

1.4.2. Synchronisation répartie

Dans le cadre des applications réparties, il est naturel de souhaiter pouvoirexécuter en parallèle, sur différents sites, des objets réactifs qui ne pourront alorscommuniquer que par échanges de messages asynchrones. Ceci s’applique enparticulier à notre gestion de tâches, qui, si elle est dupliquée sur un ensemble desites interconnectés, permet de synchroniser l’exécution de tâches réparties. Ildevient en effet possible, sous certaines conditions que nous allons définir, departager des événements concernant la gestion des tâches entre les différentsnoyaux.



L’exécution répartie d’objets réactifs peut se faire de trois façons différentes :

• Asynchrone : les objets s’exécutent en parallèle, et communiquent sanssynchronisation. La décision de démarrer une réaction ne dépend qued’informations locales, par exemple la réception d’un signal provenant d’unobjet distant. Ce mode d’exécution ne garantit aucune propriété sur lesexécutions des réactions. En particulier on ne peut assurer que deuxsignaux émis dans la même réaction par un objet seront traités dans unemême réaction par un objet distant, car leur réception peut être espacéedans le temps en raison de l’incertitude de la durée des communications.Les instants des différents objets n’ont aucun lien entre eux.

• Synchronisée : Les réactions des objets sont synchronisées suivant unesémantique précise. Plusieurs peuvent être définies, qui décrivent les règlespartagées par tous pour déclencher une réaction. On peut définir, parexemple, que les objets réagissent en séquence, ou bien, comme dans lemodèle développé pour le projet SATURNE [ADE93], que les objetsréagissent en parallèle, mais tous à la même vitesse : un objet ne peutcommencer une réaction que si tous les autres objets ont exécutéexactement le même nombre de réactions que lui. Une synchronisation dece type assure un comportement déterministe de l’ensemble des objets.

• Temporellement synchronisée : La sémantique de la synchronisation prenden compte l’avancement du temps, c’est-à-dire que le comportement desréactions est défini à l’aide de contraintes temporelles. Cet ancrage de lasynchronisation dans le temps permet la conception de systèmes temps-réel, en offrant, en plus du déterminisme, des garanties temporelles surl’exécution des réactions. C’est cette approche que nous allons développerdans cette thèse.

Dans un premier temps, il va nous falloir proposer un modèle sémantique del’exécution d’objets réactifs répartis. Ce problème a déjà été étudié, en s’appuyantsur l’hypothèse de synchronisme faible introduit par R. Milner [MIL83], etappliqué à l’exécution d’objets réactifs synchrones répartis. Nous reprenons danscette étude le modèle sémantique du projet SATURNE, nommé COREA(COmmunicating REactive Automata) [ADE93].

Puis nous définirons un modèle d’exécution, qui permettra le traitement desréactions conformément à la sémantique que nous aurons définie. Pour cela nousnous baserons sur une base de temps constituée d’un treillis d’instants. A chacunde ces instants (qui sont en fait des intervalles de temps de durée fixe) un objetréactif pourra considérer les événements à son entrée et émettre des événements àsa sortie. Ainsi la réception et l’émission d’événements seront limités à cesintervalles de temps, et nous montrerons que si la période et la durée de cesintervalles sont correctement choisis, nous pourrons garantir le respect de lasémantique de COREA.



site i

site j

site k

site l

intervalle pendant lequel sont émis/reçus des événements

temps

Treillis temporel

Appliqué à notre gestion de tâches, ce treillis définit des intervalles pendantlesquels d’une part sont prises les décisions d’ordonnancement, et d’autre part sontcommuniqués les événements aux applications. Ces dernières possèdent donc ellesaussi une grille temporelle qui rythme leur exécution, avec un décalage, parrapport au treillis initial, de la durée de la réaction de la gestion des tâches.

Ce modèle d’exécution peut être rapproché de celui proposé dans [KOP92] : H.Kopetz y présente comment reconstituer un ordre temporel sur des événementsdans un environnement réparti, et assurer la simultanéité de leur prise en compte,sans protocole autre que celui de la synchronisation d’horloges. Pour cela, lesystème se base sur une base de temps clairsemée (sparse time), similaire autreillis que nous avons défini. La granularité de cette base de temps est calculée enfonction de la précision de la synchronisation des horloges et de la durée maximumde communication des événements. Le coût des protocoles assurant les mêmespropriétés étant souvent supérieur à cette granularité, le système accroît sesperformances tout en libérant les ressources qu’auraient nécessité les protocoles.Notre gestion de tâches répartie est un support de ce modèle, et nous verronscomment utiliser les résultats de H. Kopetz dans notre réalisation.

Le chapitre 4 de cette thèse définit un modèle sémantique et un modèled’exécution des objets réactifs répartis, puis une implantation réelle y estprésentée, qui constitue un exécutif synchrone réparti.



Chapitre 2.

Gestion synchrone des tâches

Après avoir défini en quoi consiste la gestion des tâches dans un systèmed’exploitation, nous présenterons les trois sous parties de cette gestion auxquellesnous allons nous intéresser : les interruptions, les threads et la gestion du temps.Nous présenterons les outils utilisés par CHORUS pour réaliser la synchronisationde ces composants. Puis nous proposerons une modélisation de cette fonction dusystème.

2.1. Portée de l’étude

Une tâche peut être considérée comme l’unité élémentaire de traitement d’uneapplication informatique. Généralement, elle consiste à traiter des données, c’est-à-dire à recevoir des données et à en émettre. Pour cela la tâche doit avoir à sadisposition un ensemble de moyens : de la mémoire, un ou plusieurs threads pourexécuter le code, des mécanismes de communications pour recevoir et émettre desdonnées de/vers le monde extérieur, ou pour coopérer avec d’autres tâches...

La gestion des tâches comporte deux aspects distincts : d’une part la gestion deleur exécution, et d’autre part la gestion de leurs ressources.

Cette dernière a pour objectif de gérer les allocations et libérations deressources pour les tâches, ainsi que la fourniture d’une interface de manipulationde ces ressources. Dans les systèmes temps réel, l’indisponibilité de ressources enquantité et en temps voulu peut être la cause d’une violation des contraintes d’uneapplication. Il peut donc être nécessaire de réserver des ressources avant d’enavoir besoin, afin d’être sûr de leur disponibilité.

Nous ne nous intéressons pas ici à ce type de gestion, c’est sur le contrôle del’exécution que nous allons porter notre étude.

La gestion de l’exécution des tâches est un traitement de nature réactive : lesystème, dans un état particulier, détecte un ou plusieurs événements, modifie sonétat en conséquence et produit éventuellement d’autres événements. Elle est donc‘naturellement’ réalisable par objets réactifs.

Gestion synchrone des tâches 37


La gestion des tâches doit offrir les outils permettant la concurrence et lasynchronisation des threads. CHORUS propose trois niveaux de synchronisation :un premier niveau permet de manipuler directement l’état des threads à partir deprimitives de blocage, un deuxième, construit au-dessus du premier, offre desabstractions telles que les sémaphores et les mutex, et le troisième est un systèmede communications par messages. Notre étude se situe principalement au premierde ces niveaux, que nous reproduirons fidèlement. Cependant nous réaliseronsaussi une gestion de sémaphores et mutex afin d’offrir une interface utilisateurplus riche. La gestion des communications n’est pour l’instant pas traitée.

Les événements pertinents de la gestion des exécutions des tâches sont de troisordres :

• Les interruptions, qui sont les seuls événements qui puissent interromprel’exécution d’un thread, en dehors d’une opération initiée par le thread lui-même. Ces interruptions peuvent être de natures différentes, et nous lesprésenterons.

• Les événements d’ordonnancement provoqués par les threads (création,activation, blocage, effacement... de threads). Ils déterminent les instantsauxquels est décidé quel thread sera élu et disposera du processeur. C’estl’ordonnanceur qui réalise cette élection. Nous présenterons les phases de lavie d’un thread, ainsi que les états dans lesquels il peut se trouver.

• Les événements temporels, qui sont eux aussi des événementsd’ordonnancement, mais provoqués par des interruptions. Ces événementssont utilisés dans l’ordonnancement CHORUS, mais ils pourront avoir unrôle encore plus important dans une gestion de tâches temps réel, mettanten oeuvre des politiques d’ordonnancement prenant en compte descontraintes de temps (échéances, périodes...) pour les exécutions desthreads.

2.2. La gestion des tâches CHORUS

2.2.1. Les interruptions

Le terme ‘interruptions’ regroupe les événements qui peuvent suspendrel’exécution d’un programme le temps d’exécuter du code traitant cet événement. Ilexiste différents types d’interruptions, qui proviennent d’origines distinctes. Nousallons examiner ce qui les différencie.

2.2.1.1. Origine des interruptions

Les interruptions matérielles

La carte mère des ordinateurs génère des signaux d’interruption à destinationdu processeur. Ces interruptions proviennent d’éléments externes au processeur :cartes gérant les éléments périphériques, horloge, calculateur... A l’exception d’unsignal, le NMI (Non Maskable Interrupt), ces signaux sont masquables

38 Gestion synchrone des tâches


globalement et individuellement, c’est-à-dire que l’on peut configurer le processeurde telle sorte qu’il ne voit pas leurs occurrences.

Les exceptions

Une exception, aussi appelée déroutement, est générée par l’occurrence d’uneerreur (division par 0, défaut de page, code opération invalide...) ou d’une situationexceptionnelle (point d’arrêt, ou fin d’instruction en mode pas-à-pas), qui empêchel’exécution de l’instruction en cours. Lorsque le processeur détecte une tellesituation, il interrompt le travail en cours pour traiter le gestionnaire d’exceptioncorrespondant à la situation détectée. A la fin de ce traitement, il revient autravail interrompu, dans la mesure où l’état du système le permet.

Les interruptions logicielles

Ces interruptions sont aussi appelées trappes ou appels au superviseur. A ladifférence des deux types présentés ci-dessus, elles sont explicitement déclenchéespar le programme interrompu. Leur fonction est de permettre l’appel, depuis unprogramme utilisateur, d’une opération du système d’exploitation exigeant desdroits dont le programme appelant ne dispose pas. Elles sont traitées par lesystème de la même façon que les interruptions matérielles ou exceptions : lecontexte d’exécution du programme interrompu est sauvegardé, le processeurpasse en mode superviseur, et le fil d’exécution est transféré à une adressecorrespondant au numéro d’interruption appelé.

2.2.1.2. Synchronisme / asynchronisme des interruptions

Il faut distinguer, dans les trois types d’interruptions que nous venons deprésenter, deux grandes catégories du point de vue du transfert du fil d’exécution :

Les exceptions et interruptions logicielles : synchrones

Ces interruptions sont provoquées par l’exécution d’une instruction, quel’interruption ait lieu en début ou en fin de cette exécution. Ces interruptionsdoivent donc être exécutées au moment ou elles se produisent, car elles sontnécessaires à l’exécution : si un défaut de page est détecté, il est nécessaire decharger immédiatement la page manquante pour pouvoir exécuter l’instruction.Pour cette raison, nous les qualifions de synchrones.

Les exceptions sont un appel synchrone implicite (l’appel ne figure pas le code),alors qu’une interruption logicielle est un appel explicite (l’appel est présent dansle code).

Les interruptions matérielles : asynchrones

Les interruptions matérielles, par contre, ne sont pas liées au programme quis’exécute au moment de leur occurrence, elles gardent donc leur sens si elles nesont pas traitées à la fin de l’instruction pendant laquelle elles se sont produites,et de l’autre coté l’application peut continuer à s’exécuter même si l’interruptionn’est pas traitée. Nous les qualifions donc d’asynchrones.



Toutefois, il faut, dans la mesure du possible, avoir terminé le traitement d’uneinterruption avant son occurrence suivante. Pour cela, le temps de traitementd’une interruption doit être inférieur à l’intervalle minimum entre deuxoccurrences de cette interruption. Cependant, même si cette règle n’est pasrespectée, la gestion des interruptions peut être correcte si l’occurrence del’événement “deux occurrences d’une interruption sont distantes d’un intervalle detemps inférieur à la durée nécessaire au traitement de cette interruption” estsporadique. Dans ce cas, l’asynchronisme permet de traiter toutes les occurrencesen différant celles survenues pendant le traitement de l’occurrence les précédant.

Incidences pour notre modélisation

L’existence de ces deux types d’interruptions va avoir une incidence importantesur la gestion de ces événements. En effet on constate que nous nous trouvons enprésence de deux sources d’événements : les threads, volontairement(interruptions logicielles) ou non (exceptions), et le matériel. La machined’exécution de notre système devra donc prendre en compte la concurrence entreces deux sources, et différer le traitement d’un événement de l’un pendant letraitement d’un événement de l’autre.

2.2.2. Les threads, leur vie

Pour pouvoir modéliser la gestion des tâches dans un système, il est nécessairede savoir quelles sont les différentes étapes de la vie d’un thread, c’est-à-dire avoirune liste des états possibles d’un thread et la description des transitionspermettant de passer d’un état à un autre. Classiquement, les états d’un threadsont représentés par un graphe du type :

Bloqué

Elu

Prêt

attendre()

attendre() promotion

événement

préemption

Etats de base d’un thread

Sur ce graphe, nous pouvons voir qu’à un instant donné un thread est soitBloqué, c’est-à-dire en attente d’un événement nécessaire à son exécution, soitPrêt, c’est-à-dire en attente du processeur pour s’exécuter, soit Elu, auquel cas ilest en train de s’exécuter. Cette vision est très générale, et elle nécessite d’être



précisée. En effet les systèmes utilisent en général des sous-états pour chacun deces 3 principaux.

2.2.2.1. Les états d’un thread Chorus

Etats bloqués

On distingue trois états de blocage :

• Etat suspendu : Chaque thread possède un compteur de suspension,initialement à la valeur -1 ou 0 (c’est un paramètre de la création). Lorsquece compteur est négatif, le thread est dans l’état suspendu. Lorsqu’il devientpositif le thread quitte l’état suspendu.

• Etat d’arrêt : Il est possible d’arrêter un acteur CHORUS, auquel cas tous lesthreads qu’il contient prennent l’état stoppé.

• Etat d’attente : Un thread peut se mettre en attente d’un événement dusystème (expiration d’un timer, libération d’un sémaphore...), il est alorsdans un état d’attente qui est quitté soit à l’occurrence de l’événement, soità l’expiration d’une échéance si l’utilisateur en a fixé une. Le programmeurdispose aussi d’une opération d’annulation (abort) pour interrompre uneattente en cours.

Ces états ne sont pas exclusifs, ils peuvent être combinés, ce qui forme unensemble de sept états de blocage possibles.

Etats intermédiaires

Les threads CHORUS possèdent un état intermédiaire pour gérer leurdestruction. Cet état, que l’on pourrait appeler ‘en phase de destruction’ seraexpliqué dans le paragraphe sur la destruction d’un thread.

Ils possèdent également un état ‘en cours de création’, que prennent les threadscréés en mode suspendu jusqu’à ce qu’ils deviennent prêts.

Sous-états communs

Un thread, qu’il soit prêt, bloqué ou élu, peut-être dans les sous-états suivants :

• Avec opération(s) masquée(s). En effet chaque thread possède un masquequi permet de définir un ensemble d’opérations (la suspension, l’arrêtinconditionnel, l’annulation d’attente, et l’effacement) qui seront sans effetimmédiat, elles sont alors marquées ‘en suspens’ (pending), et seronteffectivement exécutées en différé (deffered) au moment du démasquage.Toutefois une seule occurrence de chaque opération masquée est mémoriséeen suspens. Si la même opération est invoquée n (n>1) fois pendant quecette opération est masquée, alors n-1 invocations seront perdues.



• Avec attente annulée. Il est possible d’annuler les opérations d’attenteavant leur appel. Chaque thread possède à cet effet un compteurd’annulation. Lorsqu’il est supérieur à zéro (n), les n prochains appelsd’opérations d’attente seront annulés.

• En mode système/utilisateur. La différenciation de ces deux modesd’exécution est faite dans tout système d’exploitation, car ils impliquent unegestion particulière en terme d’accès aux données. Un thread passe dumode utilisateur au mode système lorsqu’il provoque une interruptionlogicielle ou une exception, le temps de traiter cet événement.

• Avec contexte visible. Un thread est dans ce sous-état lorsqu’il a été créé enmode suspendu et qu’il n’a pas encore été redémarré, ou bien lorsqu’il estdans une situation d’exception non résolue. Dans ce sous-état il est possibled’accéder à son contexte depuis l’extérieur du noyau, en lecture et enécriture, grâce à la primitive threadContext . Ce point est particulier ausystème CHORUS, nous ne le traiterons pas dans notre modélisation

2.2.2.2. Les événements

Nous allons maintenant examiner les événements qui permettent de passerd’un état à un autre. Ces événements proviennent de différents éléments dusystème :

• déclenchés par l’invocation d’une opération de l’interface de programmationofferte par le système, ils peuvent venir soit du thread concerné parl’événement, soit d’un autre thread qui connaît sa référence;

• de l’ordonnanceur, ils sont la conséquence d’un événement venant de seproduire, du type expiration d’un timer, ou modification de l’état d’un autrethread;

• d’un composant du système, qui a besoin de contrôler l’exécution du threadqu’il sert; par exemple le mécanisme de RPC masque certaines opérationssur le thread pendant l’invocation distante.

La création

Un thread CHORUS peut être créé dans l’état prêt ou suspendu. Créer un threaddans l’état suspendu permet de lire ou écrire dans son contexte.

La destruction

La destruction d’un thread, sous CHORUS, se fait en deux temps.

1- la requête de destruction peut être demandée par le thread lui-même oupar un autre, par contre l’opération de destruction est toujours exécutée parle thread lui-même : il se suicide. Dans le cas où c’est un autre thread quifait la requête, l’ordonnanceur modifie l’état du thread afin qu’il prenne le



processeur le plus vite possible : sa priorité est affectée avec la valeurmaximum, et il passe à l’état prêt.

2- Le thread à détruire, s’il ne s’exécutait pas déjà, prend le processeur. Dansle cas où l’opération de déstruction est masquée pour ce thread, il garde lamain jusqu’à son démasquage. Il est alors détruit lors du premier appel àune opération du noyau, qui peut être soit volontaire (appel système), soitprovoqué par le traitement d’une interruption.

L’arrêt inconditionnel

Les opérations stop() et start() appelées sur un acteur bloquent etdébloquent tous les threads possédés par cet acteur. C’est un mécanisme à bascule,qui n’est basé que sur un booléen (et non sur un compteur). Il faut attendre un (etun seul, quel que soit le nombre de ‘stop ’ faits sur l’acteur) appel à la fonction‘start ’ de l’acteur pour quitter cet état.

L’arrêt avec compteur

L’opération threadSuspend() permet de décrémenter le compteur desuspension d’un thread. Cette opération peut être invoquée depuis le thread luimême ou d’un autre, du même acteur ou non. L’opération inverse estthreadResume() .

L’attente

Les attentes sont faites sur l’initiative du thread lui-même, aucun thread nepeut mettre en attente un autre thread. Une attente peut se faire soit uniquementsur une échéance, soit aussi sur un événement donné. Dans ce dernier cas il y adeux causes de sortie possibles de ce mode d’attente : expiration de l’échéance ouoccurrence de l’événement. Il existe aussi une troisième cause de réveil :l’annulation de l’attente, cette opération étant demandée par un thread autre quecelui en attente. Le thread réveillé est informé de la cause de son réveil par lavaleur de retour des opérations d’attente.

L’opération d’attente la plus simple est threadDelay(n) , qui permet à unthread de se bloquer pendant n millisecondes. Lorsque ce temps est écoulé lethread est réveillé.

Deux mécanismes du système peuvent aussi faire passer dans l’état d’attente.Ces opérations de blocage permettent l’attente d’un événement avec une échéance,dont la valeur peut aller de 0 (pas d’attente, l’événement doit être immédiatementdisponible) à l’infini (l’événement sera éternellement attendu s’il ne se produitpas). Arrivé à l’échéance, l’opération retourne une erreur.

• les sémaphores (et donc les mutex qui les utilisent), avec l’opérationsemGet() ; l’événement attendu est la libération du sémaphore parl’opération semRel() .



• les communications inter-processus (IPC), avec l’opération ipcReceive() ;l’événement attendu est alors l’arrivée d’un message envoyé par l’opérationipcSend().

Ces opérations mettent toujours en attente le thread qui les a invoquées, iln’est pas possible de mettre en attente un autre thread que soi-même.Inversement, c’est toujours un autre thread qui produit l’événement attendu, lethread en attente étant bloqué il ne peut pas le produire.

2.2.3. L’ordonnancement

L’ordonnancement a la charge de choisir le thread qui aura le processeur, etdonc s’exécutera. Il réagit pour cela aux événements d’ordonnancement, c’est-à-dire aux événements pouvant entraîner une modification de l’allocation duprocesseur.

Tout ordonnancement comporte un aspect générique et un aspect propre àchaque système. L’aspect générique concerne la prise en compte des événementsd’ordonnancement, et les mécanismes de changement de thread courant. Cettegestion fait appel à une politique d’ordonnancement, qui établit la règle suivantlaquelle les threads sont choisis pour s’exécuter. Cette politique résulte d’un choixfait par les concepteurs du système.

Le choix fait par CHORUS est celui d’une politique d’ordonnancementpréemptive à priorité de 0 à 255. Le thread courant est toujours le thread prêt leplus prioritaire. Pour les threads ayant une priorité entre 128 et 255, CHORUSapplique une politique de temps partagé : les threads de même priorité sontordonnancés de façon cyclique pendant un quantum de temps qui leur est imparti.

Les événements d’ordonnancement à prendre en compte sont

• le passage d’un thread, qui peut être le plus ‘prioritaire’, à l’état prêt;

• le passage du thread courant à l’état bloqué, qui entraîne l’élection d’unautre thread pour lui succéder;

• l’expiration du quantum de temps du thread courant, qui doit permettre àun autre thread de même priorité de s’exécuter;

• la demande de destruction d’un thread, qui rend ce thread plus prioritairepour qu’il puisse se détruire lui-même.

La demande de création d’un thread n’est un événement d’ordonnancement quesi ce thread est créé dans l’état prêt, auquel cas nous nous trouvons dans lasituation du premier point.

2.2.4. La gestion du temps

Les interruptions horloge sont traitées par un gestionnaire dont le rôle consisteà :



• maintenir l’horloge du système;

• mettre à jour les temps d’exécution du thread courant (utilisateur etsuperviseur);

• parcourir la liste des timers pour voir quels sont ceux ayant expirés. Ceuxlà sont effacés de la liste et la fonction qui leur est associée est exécutée.

Les timers sont un triplet <date, fonction, arguments>. Les opérationsd’attente mentionnées précédemment les utilisent pour gérer les échéances, lafonction appelée est alors l’opération de réveil du thread.

2.2.5. Synchronisation dans le noyau

2.2.5.1. Verrouillage du noyau

Le noyau gère un compteur de verrouillage, que l’on appelle un verrou, parthread. Deux opérations (KnLock() et KnUnLock() ) permettent d’incrémenter et dedécrémenter ce verrou. Lorsque le verrou est supérieur à zéro, on dit que le noyauest verrouillé, il n’y a plus de préemption. Une opération (KnTryLock() )n’incrémente le verrou que s’il est à zéro, sinon il retourne une valeur d’erreur.Ceci permet de savoir si le noyau est déjà verrouillé. Même lorsqu’il a verrouillé lenoyau, un thread peut perdre le processeur, a condition qu’il fasse lui même lademande. Son verrou est alors sauvegardé dans son contexte, et le nouveau threadordonnancé impose son propre verrou, qui peut être à zéro. La préemption est dansce cas autorisée. Lorsque le thread ayant verrouillé reprend le processeur, ilrepositionne la valeur de son verrou, la préemption est donc de nouveau interdite.Le verrou ne masque pas les interruptions. L’opération de déverrouillage estappelée au retour de chaque interruption.

L’inhibition de la préemption est gérée par l’opération de déverrouillageKnUnLock , qui ne fait pas que décrémenter le verrou, elle :

• exécute toutes les opérations différées (opérations qui n’ont pu êtreexécutées à cause du verrouillage);

• détruit le thread courant s’il est marqué ‘effacé’;

• réalise la préemption du thread courant si elle a été détectée nécessaire.

Ces trois opérations ne sont effectuées que si le verrou passe de 1 à 0, c’est-à-dire si le KnUnLock va effectivement déverrouiller le noyau. C’est cette contraintequi assure que la préemption n’a pas lieu tant que le noyau est verrouillé.

2.2.5.2. Gestion des threads

Toutes les opérations de l’interface système concernant les threads verrouillentle noyau avant d’accéder aux données du thread.



A sa création, le verrou d’un thread vaut 1. La première fois qu’un thread prendle processeur il déverrouille automatiquement le noyau avant d’exécuter sapremière instruction. Cette méthode permet d’avoir une gestion uniforme deschangements de contexte, que le thread prenant le processeur se soit déjà exécutéou non. En effet, puisque tout changement de contexte se passe alors que le noyauest verrouillé, si l’on n’appliquait pas cette méthode il faudrait déverrouillerartificiellement le noyau pendant ce premier changement de contexte, ce qui n’estni ‘propre’ (on ne pourrait pas utiliser KnUnLock , puisque c’est lui même quiexécute le changement de contexte), ni souhaitable (il risquerait d’y avoir unepréemption pendant le changement de contexte).

2.2.5.3. Gestion des interruptions

Les interruptions matérielles

Plusieurs interruptions matérielles peuvent avoir lieu simultanément, il fautdonc prévoir un mécanisme permettant la concurrence de traitement desinterruptions.

Les interruptions matérielles ne sont pas exécutées par des threads standards.La détection de l’occurrence d’une interruption génère la création et le démarraged’un thread particulier pour exécuter son gestionnaire, ce thread ne perd leprocesseur que lorsqu’il a fini son traitement ou lorsqu’une autre interruption seproduit, générant l’exécution (préemptive) de son gestionnaire. Il n’existe pas demoyen de bloquer un gestionnaire d’interruption, puisqu’il n’est ni un thread, ni unacteur, et que toutes les opérations de blocage portent sur l’une de ces deuxentités. Aucun thread ‘normal’ ne peut prendre le processeur. L’ordonnanceur saitqu’un gestionnaire d’interruption est en cours d’exécution grâce au niveaud’interruption courant, qui est une variable entière du noyau indiquant le nombrede gestionnaires d’interruption actifs.

Seuls quelques appels systèmes sont autorisés pendant le traitement d’uneinterruption. Ces opérations permettent la gestion des données du noyau (timers,date, contexte, table des interruptions/exceptions/trappes...), l’émission d’un mini-message, et la libération d’un mutex ou d’un sémaphore. Aucune opération de lagestion des threads n’est autorisée. C’est une restriction très forte. On souhaiteraitpar exemple pouvoir incrémenter le compteur de suspension d’un thread(threadResume ) qui serait chargé du traitement de l’interruption. Le thread feraitalors une boucle <traiter interruption; décrémenter compteur de suspension(threadSuspend )>. Le compteur de suspension du thread peut être remplacé parcelui d’un sémaphore, mais cela nécessite que le thread et le gestionnaired’interruption soient dans le même espace d’adressage, ou bien que la pagemémoire contenant le sémaphore soit ‘mappée’ dans l’espace d’adressage duthread, ce qui est lourd à gérer. Il est impossible de créer un thread, d’en bloquer,ou de les manipuler de quelque façon que se soit.

Un gestionnaire d’interruption ne peut pas verrouiller le noyau sans avoir testéavant la valeur du verrou. En effet une interruption peut préempter un thread quia verrouillé le noyau, ou une autre interruption, elle ne peut donc pas supposer



qu’elle a l’exclusivité de ce verrou. Les gestionnaires d’interruptions, s’ils nepeuvent verrouiller le noyau, enregistrent dans la liste des différés les opérationsqu’ils auraient souhaité exécuter.

Les exceptions et interruptions logicielles

Ces interruptions sont exécutées par le thread en cours au moment de leuroccurrence. Le thread passe alors en mode superviseur, ce qui lui permet d’accéderà l’espace d’adressage système. Il utilise alors sa pile système.

2.2.5.4. Gestion du temps

L’interruption horloge est une interruption matérielle, son traitement respectele comportement standard de ce type d’événement. Elle possède en plus certainespropriétés que nous détaillons ici.

Lorsque l’interruption horloge se produit alors que le noyau est verrouillé, lestimers ne sont pas traités immédiatement, leur traitement est ajouté (une seulefois quel que soit le nombre d’interruptions pendant lesquels le noyau estverrouillé) à la liste des opérations différées. Les timers seront donc traités audéverrouillage du noyau.

Tant que le noyau est verrouillé le gestionnaire d’interruption horloge n’exécutepas les tests d’expiration de temps des threads, ce qui évite une inutile gestion dutemps partagé puisque de toute façon aucune préemption ne peut se produire. Cestests sont mémorisés dans la file des opérations différées, ils seront donc exécutésau moment du déverrouillage.

L’insertion d’un nouveau timer ne peut se faire que si le noyau n’est pasverrouillé, sinon l’insertion est différée. De même pour l’annulation d’un timer.

2.3. Modélisation

2.3.1. Objectifs

L’implantation actuelle du noyau CHORUS est faite en langages deprogrammation classique (C/C++/assembleur), ce qui rend impossible toute preuveformelle du comportement du système. Le contrôle du système est éparpillé dansl’ensemble du code, ce qui rend sa lecture difficile, et en conséquence samaintenance/modification est complexe.

Nous allons présenter une autre façon de réaliser la gestion des tâches, enisolant la partie contrôle, écrite en langage synchrone, de la gestion des données,qui reste en langage classique. Nous obtenons alors la base d’un micro-noyausynchrone, dont nous pouvons prouver le comportement à l’aide des outils etformalismes associés à la programmation synchrone.

Pour cela, nous identifions différents composants fonctionnels dans la gestiondes tâches, afin de définir les modules synchrones à développer. La gestion desdonnées sera écrite en C++, elle est appelée depuis le code ESTEREL. Nous



définissons ensuite l’infrastructure nécessaire pour exécuter et faire communiquerces modules. Le résultat de ce travail est une gestion des tâches exécutable dansdes conditions réelles, réaliste (pas de suppositions simplificatrices...) et complète(pas d’impasse...). Puisque nous ne réécrivons pas la totalité du systèmed’exploitation, nous proposons une implantation de notre réalisation à un niveauutilisateur, au-dessus de noyau CHORUS.

2.3.2. Définitions

Le terme événement désigne l’occurrence dans le système d’une situationdonnée. Un signal est la représentation ESTEREL d’un événement, il est composéd’un booléen, indiquant sa présence ou son absence, et éventuellement d’unevaleur. On distingue trois type de signaux :

• Les signaux entrants, permettant au monde asynchrone d’informer lemonde synchrone de l’occurrence d’un événement;

• Les signaux internes, qui communiquent des informations à l’intérieur dumonde synchrone.

• Les signaux sortants, informant le monde extérieur de l’occurrence d’unévénement produit par le monde synchrone.

Nous appelons module synchrone le code d’un module ESTEREL. Il dispose d’uneinterface d’entrée, composée de signaux entrants, et d’une interface de sortie,composée de signaux sortants.

La compilation d’un module synchrone produit un automate en code OC(langage standard de description d’automate), qui est lui même traduit dans unlangage cible, le C dans la version standard du compilateur. Nous utilisons uneautre traducteur OC, produisant une classe C++ par automate, qui s’intégre dansun ensemble de classes permettant la connexion et l’exécution de ces automates[BOU94].

L’instanciation d’une classe d’automate produit un objet synchrone, qui seprésente comme un objet standard, mais qui encapsule du code synchrone.L’interface de cet objet permet de positionner des signaux d’entrée du code réactif,et de récupérer les signaux de sortie produits par ce code.

Il est possible de connecter un signal de sortie SIG_O d’un objet synchrone à unsignal d’entrée SIG_I d’un autre objet synchrone, l’émission de SIG_O provoqueraalors l’occurrence de SIG_I . Composer des modules synchrones consite à définir lesconnexions entre ces modules, et la nature de leurs communications.

2.3.3. Présentation des composants

Les composants du noyau modélisés ont pour mission la gestion des threads etinterruptions telle que nous l’avons présenté. Ils constituent un préparateur decontexte d’exécution. Ils sont stimulés par l’occurrence des événements de la



gestion des tâches, et réagissent en en déduisant un nouveau contexte d’exécution.A la fin de cette réaction, le fil d’exécution passe sur ce contexte.

Ces composants sont constitués de plusieurs modules synchrones. Uncomposant est découpé en plusieurs modules lorsque :

• la compilation du module réalisant l’ensemble du composant produit unautomate de taille trop importante;

• le composant possède des fonctionnalités qui doivent s’exécuter à différentsmoment de l’exécution du système. Par exemple, le composant Time estdivisé en un module TimeGuard , exécuté avant le composant Thread, et dumodule TimerMgr , exécuté après.

Les composants sont au nombre de quatre :

Applications

Système

Matériel

n * Thread

Th1Th2

Th3...

autres objetssystème

InterruptTime

Scheduler

Les composants synchrones de notre mise en oeuvre (grisés)

1- Interrupt

Réceptionne les signaux d’interruptions et les redirige vers les modulesconcernés. Il contient deux modules, InterruptMgr et SysMode.

InterruptMgr reçoit les signaux d’interruptions matérielles. En réaction, illance les gestionnaires d’interruption et gère leur contexte. Il avertit aussi



l’ordonnanceur des passages en mode interruption, car dans cette situationl’attribution du processeur doit être suspendue.

SysMode reçoit les signaux de trappes et exceptions, en provenance duprocesseur, et les redirige vers le thread en cours d’exécution, afin qu’il passe dansle mode système. Lorsque l’on est en mode interruption, il n’est pas nécessaire deprévenir le gestionnaire d’interruption en cours, puisqu’il est déjà en modesystème.

2- Time

Traite l’interruption horloge, et gère les timers. Il contient les modulesTimeGuard et TimerMgr .

TimeGuard surveille la prochaine date d’expiration de timer, et avertit de sonoccurrence le ou les threads qui l’ont programmé. Il connaît cette date grâce aumodule TimerMgr , qui gère la liste des timers demandés par les threads, et endéduit le prochain.

3- Scheduler

Actionne une politique d’ordonnancement pour attribuer le processeur auxthreads. Pour cela, il reçoit les informations d’état des threads, et le moded’exécution courant en provenance du composant Interrupt . Il est divisé en unmodule générique, SchedBase , et un module spécifique, TimeSlice , qui implémentela politique d’ordonnancement du temps partagé de CHORUS.

4- Thread

Gère toutes les modifications que l’on peut apporter à l’état d’un thread. Ilexiste un composant Thread par thread. Le nombre d’états à gérer étantimportant, ce composant contient cinq modules.

Les modules thSuspend , thStop et thSleep gèrent les états respectivementsuspendu, arrêté et en attente. Ils communiquent avec le module thMain , qui endéduit l’état global du thread : prêt ou bloqué. Cette information est communiquéeau composant Scheduler .

Le dernier module, thTrapExc , détermine si le thread est en mode système ouutilisateur. Il dispose, pour cela, d’un paramètre de création des threads, et desoccurrences des trappes et exceptions en provenance de Interrupt .

Nous allons détailler les fonctionnalités et propriétés de chacun de cescomposants, et présenter leurs modules. Le code ESTEREL de ces modules estdonné en annexe.

2.3.4. Vérifications

Les méthodes de vérifications formelles d’une application passent en généralepar une réécriture dans un langage spécifique du comportement de l’application.



Le problème est que cette réécriture peut ne pas représenter exactement lecomportement de l’application, la vérification ne porte pas sur le code exécuté,mais sur son comportement supposé. Les langages synchrones étant traduits enautomates à états finis, il est possible de faire directement des vérifications sur lecode qui est exécuté. Des études ont déjà été menées mettant en évidence lesavantages de cette approche [CAS94].

2.3.4.1. Vérifications graphiques

Le langage ESTEREL possède un environnement de développement qui permetde simplifier considérablement cette tâche : à partir du graphe de l’automategénéré, un outil nous permet de faire des réductions sur certains signaux,montrant ainsi des comportements simples de l’automate. Voici quelquesindications permettant la lecture de ces graphes :

Les états sont symbolisés par des carrés. L’état initial est le carré ayant unebordure doublée. Une transition d’un état à un autre a pour label la combinaisonde signaux qui provoque cette transition. Un nom de signal suivi du caractère ‘?’indique la présence du signal. L’émission des signaux de sortie n’est représentéeque sur certains graphes, elle est symbolisée par le nom du signal suivi ducaractère ‘!’. Le caractère ‘.’ indique un ET logique entre les deux expressions quil’encadrent.

2.3.4.2. Vérifications formelles

Il est possible de vérifier formellement un comportement d’un module ESTEREL.L’automate généré par sa compilation est un système de transitions Θ qui estdéfini par :

• un ensemble de d’actions A;

• un ensemble d’états Q fini possédant un état initial q0;

• une relation de transitions T ⊂ Q × A × Q. On note q q'a → la transition( , , ')q a q .

Une action d’un automate ESTEREL peut être :

• une émission de signal, notée “!” (e.g. “sigOut!”);

• la présence d’un signal en entrée, notée “?” (e.g. “sigIn?”);

• l’absence d’un signal en entrée, notée “#” (e.g. “sigIn#”)

• l’occurrence simultanée de plusieurs de ces trois actions de base, notée “.”.Un signal ne peut pas être présent et absent à la fois : l’action“sigIn?.sigIn#” n’a pas de sens, mais l’action “sigIn?.sigOut!” est valide.

Nous utiliserons l’écriture “/s” pour désigner l’ensemble des actions possédantl’action de base s, ceci afin de ne pas avoir à énumérer toutes les actions qui la



contiennent. Les opérateurs and, or et not permettent d’exprimer respectivementles relations logiques ET, OU et NON entre des désignations d’actions.

De plus nous disposons de la notation “true” pour désigner l’ensemble desactions possibles. Toute action est conforme à true.

Pour vérifier un comportement d’un automate, on souhaite le simplifier de tellesorte que n’apparaisse que la propriété que l’on étudie. Pour cela on introduit lanotion d’action abstraite, qui permet de calculer un automate dont lecomportement est déduit de l’automate initial, mais dont les transitions sontétiquetées par ces actions abstraites.

Une action abstraite Ai est un ensemble de séquences d’actions de A (Ai ⊆ A*).

Une séquence d’actions, notée “:”, est définie par :

( ' ") ( "): *q q q q q a A et u Aa u a u → → ⇔ → ∀ ∈ ∀ ∈

Un comportement peut faire intervenir plusieurs actions abstraites, qu’il fautdonc prendre en compte lors de l’observation de l’automate. Un critèred’observation C est un ensemble d’actions abstraites :

C = {Ai, Ai ⊆ A*}

Observer le système de transition Θ par le critère C consiste à construire unsystème de transition Θc qui a les propriétés suivantes :

• les états de Θc sont ceux de Θ, mais dans notre étude nous ne considéreronspas les états de Θc qui ne sont pas accessibles depuis l’état initial;

• les actions de Θc sont celles de Θ;

• q qAi → ' est une transition de Θc si et seulement s’il existe une séquence

ai d’actions de A telle que ai ∈ Ai et q qai → ' est une suite de transition deΘ.

Nous utiliserons des critères d’un type particulier, permettant l’expression decomportements complexes : un critère d’observation régulier est une liste d’actionsabstraites régulières. Celles ci sont des expressions régulières d’actions concrètes,qui utilisent trois opérateurs :

• séquence “:” : ( ' ' ') ":q q et q q q qA B A B → → ⇒ →

• somme “+” : q q q qA A B → ⇒ →+' '

q q q qB A B → ⇒ →+' '



• étoile “*” : q qA* →

q q q qA A A: * *' ' → ⇒ →

Nous ne présenterons pas ici la méthode de calcul du quotient Θc d’unautomate Θ par un critère C, pour cela on pourra se reporter à [LEC89].

Si Θc ne contient que l’état initial (Θc={q0}), ou plus exactement si aucun étatde Θc n’est accessible depuis l’état initial, alors c’est que les actions abstraites nepourront jamais se produire. C’est par ce moyen que nous démontrerons dans cedocument les comportements des modules ESTEREL : nous définirons un critère,qui ne contiendra en général qu’une seule action abstraite (régulière), et si lequotient de notre automate par ce critère nous indique que l’état initial est un étatpuits, alors nous aurons montré qu’une situation ne peut jamais se produire.

Pour effectuer ces vérifications, nous utiliserons le logiciel de vérificationMAUTO [LMV87][VER92], développé dans le même projet que le langage ESTEREL.Cet outil prend en entrée l’automate généré par la compilation d’un moduleESTEREL, nous permet d’exprimer nos critéres, et calcule le quotient de l’automatepar ses critères. Il peut faire de nombreuses autres opérations sur les automates,que nous n’utiliserons pas.

La vérification de propriétés d’un module synchrone doit permettre de certifierque son comportement est conforme à ses spécifications. Cela revient à tester lesconditions d’émission des signaux de sorties du module. Pour chaque signalsortant, on doit définir les signaux entrants et sortants avec lesquels il doit ou nedoit pas se produire, ceci en fonction de l’état de l’automate. La vérificationcompléte d’un module synchrone implique donc un très grand nombre devérifications. Toutefois certaines ne pourront pas être faites, car la conditiond’émission d’un signal ne dépendra pas uniquement des signaux présents et del’état de l’automate, mais aussi de variables internes du module synchrone, dont lavaleur, dynamique, ne peut être prise en compte dans les vérifications. Dansl’écriture du code ESTEREL, nous avons essayé de limiter au maximum cessituations, et nous signalerons les signaux pour lesquels nous n’avons pu l’éviter.

Etant donné la quantité de vérifications possibles pour chacun des modules,nous ne présenterons dans ce document que celles qui traite des propriétésessentielles du module.

2.3.5. Les interruptions : composant Interrupt

Ce composant est constitué de deux modules : InterruptMgr , qui traite lesinterruptions matérielles et SysMode, qui gère les interruptions logicielles et lesexceptions.



EnterInterruptExitInterrupt

InterruptEndInterrupt

ClockTickEnterInterruptExitInterruptAsyncInterrupt

TrapTrapRetExceptionExceptionRet

ThreadTrapThreadTrapRetThreadExceptionThreadExceptionRet

InterruptMgr SysMode

Relations entre les modules du composant Interrupt

2.3.5.1. Le module InterruptMgr

Rôle

Les interruptions physiques sont l’élément le plus près du matériel que nousmodélisons. Elles font l’objet d’un module spécial, nommé InterruptMgr , qui apour rôle :

• de déterminer si le processeur est en train de traiter une interruptionmatérielle, auquel cas nous dirons que le système est dans le modeinterruption (signaux de sortie EnterInterrupt et ExitInterrupt , àdestination de l’ordonnanceur);

• de générer le signal d’horloge du système (émission du signal ClockTick )sur occurrence d’un signal d’interruption particulier;

• d’émettre des demandes de traitements asynchrones d’interruptions(émission du signal AsyncInterrupt );

• de gérer les contextes d’exécution des gestionnaires d’interruptions à l’aided’une interface externe.

Les interruptions sont traitées de façon asynchrone vis-à-vis de ce module. Eneffet ce dernier, lors de la réception d’un signal Interrupt(integer) enprovenance du processeur, émet un signal AsyncInterrupt(integer) àdestination du monde asynchrone pour lancer le gestionnaire d’interruption, et ilattend en réponse un avis de fin de traitement d’interruption (réception du signalEndInterrupt ). Toutefois nous voulons avoir la possibilité de traiter certainesinterruptions de façon synchrone, pour cela nous utilisons un signal interne (nonvisible à l’interface) nommé isSynchInterrupt qui permet aux gestionnairesd’interruptions synchrones de signaler à ce module qu’il ne faut pas émettre lesignal de sortie AsyncInterrupt pour certaines interruptions.



Le contexte d’exécution d’un gestionnaire d’interruption est préparé par letraitement du signal AsyncInterrupt . Lorsque l’on entre dans le modeinterruption, il faut sauvegarder le contexte du thread en cours, ce qui est réalisépar la procédure save_thCtx()() . Lorsqu’une nouvelle interruption interrompt ungestionnaire d’interruption, il faut empiler le contexte de ce gestionnaire(push_ItCtx()() ). A la fin du traitement de cette nouvelle interruption, on dépilele contexte précédent (pop_ItCtx()() ). Lorsque le dernier traitementd’interruption se produit, on récupère le contexte du thread interrompu(restore_thCtx()() ).

Il faut signaler que la gestion des interruptions que nous proposons donne latotalité de l’interface système disponible aux gestionnaires d’interruptions,contrairement au noyau CHORUS.

Interface

Nom Type E/S Provenance/destination; signification

Interrupt integer E matériel; occurrence d’un signald’interruption

EndInterrupt E gestionnaire d’interruption; fin detraitement d’une interruption

ClockTick S composants Time et Scheduler ; interruptionhorloge

EnterInterrupt S composant Scheduler ; entrée dans le modeinterruption

AsyncInterrupt integer S gestionnaires d’interruptions; lancementd’un traitement asynchrone d’interruption

ExitInterrupt S composant Scheduler ; sortie du modeinterruption

Vérifications

L’automate généré par la compilation du module InterruptMgr ne possède pasd’état puits, il est donc toujours prêt à réagir à une modification de sonenvironnement.

Les deux fonctions essentielles assurées par ce module sont la distribution desinterruptions et la gestion du mode interruption. La première fonction est simple,les vérifications qui y sont associées ne sont pas présentées ici. La seconde consisteen particulier à avertir l’ordonnanceur du passage du système en modeinterruption, et de sa sortie. Vérifier le bon fonctionnement de cette fonction nousassurera que l’ordonnanceur ne donnera pas le processeur à un thread alors quel’on est en train de traiter une interruption, ou inversement que l’ordonnanceur nerestera pas bloqué en mode interruption alors qu’il n’y a plus de traitement encours.

Nous faisons tout d’abord une vérification graphique de cette fonction, à l’aided’une réduction du graphe d’états de cet automate. Le graphe complet del’automate contient 3 états, et 12 transitions :



EndInterrupt#.Interrupt#

EndInterrupt?.Interrupt#

EndInterrupt?.Interrupt#.ExitInterrupt!

Interrupt?.EndInterrupt#.AsyncInterrupt!

EndInterrupt?.Interrupt?.AsyncInterrupt!

Interrupt?.EndInterrupt#.ClockTick!

EndInterrupt?.Interrupt?.ClockTick!

EndInterrupt?.Interrupt?.ClockTick!.ExitInterrupt!

Interrupt#Interrupt?.AsyncInterrupt!.EnterInterrupt!

Interrupt?.ClockTick!

3 2

1

Ce graphe prend en compte l’ensemble des signaux du module, dont certains nesont pas pertinents pour le comportement que nous voulons étudier. Noussouhaitons disposer un graphe qui ne considére que les quatre signaux qui nousintéressent : nous voulons vérifier que les signaux AsyncInterrupt etEndInterrupt génèrent correctement les signaux EnterInterrupt etExitInterrupt . Nous avons sélectionné AsyncInterrupt plutôt que Interrupt ,pour ne pas tenir compte des interruptions synchrones, qui n’ont pas d’influencesur l’entrée et la sortie du mode interruption. La réduction du graphe sur cessignaux nous donne le résultat suivant :

AsyncInterrupt!.EnterInterrupt!

EndInterrupt?

EndInterrupt?.ExitInterrupt!

AsyncInterrupt!

EndInterrupt?.AsyncInterrupt!

1 3

Graphe d’état réduit sur AsyncInterrupt , EndInterrupt , EnterInterrupt etExitInterrupt .

Etat 1 : Pas d’interruption en coursEtat 3 : Mode interruption; une interruption est en cours de traitement

Nous avons bien les deux états que nous voulions capturer. L’état initial estl’état 1. Il n’existe pas d’autre événement qu’un signal d’interruption qui puissefaire passer de l’état 1 à l’état 3; il n’existe pas d’autre événement qu’une find’interruption qui puisse faire passer de l’état 3 à l’état 1. Dans l’état 1,l’occurrence d’un signal AsyncInterrupt fait toujours passer à l’état 3. Le moduleutilisant une variable interne pour compter le niveau d’interruption, on ne voit pasla condition qui permet de choisir entre le retour à l’état 1 ou la boucle sur l’état 3lors de l’occurrence de AsyncInterrupt .



Vérifions maintenant formellement ces propriétés. Les actions abstraitessuivantes sont composées d’une séquence de deux actions, la première (true*) estune constante toujours vraie, qui permet le parcours complet du graphe. Si lapremière action n’était pas présente dans ces formules, on ne testerait la seconde(celle dont nous voulons prouver l’inexistence) que depuis l’état initial, alors quenous voulons montrer qu’elle est impossible depuis n’importe quel état.

Une propriété essentielle doit tout d’abord être vérifiée, car d’autres propriétésreposent sur sa correction : EnterInterrupt et ExitInterrupt ne doivent jamaisêtre émis simultanément :

true* : /EnterInterrupt! and /ExitInterrupt! → faux

Regardons les conditions d’émission de EnterInterrupt . Il ne doit être émis àchaque occurrence d’une interruption traitée de manière asynchrone (signalAsyncInterrupt ) lorsque l’on n’est pas déjà en mode interruption. Le mode non-interruption est défini comme étant atteint soit (i) lorsque aucune interruptionasynchrone n’a été traitée, soit (ii) lorsque aucune interruption asynchrone n’a ététraitée depuis la dernière sortie du mode interruption (signal ExitInterrupt ).Trois propriétés vont permettre de garantir complètement ce comportement :

• EnterInterrupt ne peut être émis que si AsyncInterrupt est présent :

true* : (not /AsyncInterrupt!) and /EnterInterrupt! → faux

• EnterInterrupt est émis à chaque occurrence de AsyncInterrupt si l’onn’est pas en mode interruption :

(i) ((not /AsyncInterrupt!)*+

(ii) (true* : /ExitInterrupt! : (not /AsyncInterrupt!)*)): (/AsyncInterrupt! and not /EnterInterrupt!) → faux

• EnterInterrupt n’est jamais émis lorsque l’on est en mode interruption :

true* : /EnterInterrupt! : (not /ExitInterrupt!)* : /EnterInterrupt! → faux

Les conditions d’émission du signal ExitInterrupt sont à peu prèssymétriques : Il doit être émis sur occurrence d’une fin de traitementd’interruption asynchrone (signal EndInterrupt ) alors que l’on est en modeinterruption, et uniquement dans cette situation. Toutefois ExitInterrupt ne doitpas être émis à chaque occurrence de EndInterrupt , car il est possible qu’uneinterruption en interrompe une autre, auquel cas sa terminaison ne fait pas sortirdu mode interruption. La vérification des deux propriétés suivantes garantit cecomportement :

• ExitInterrupt n’est jamais émis si EndInterrupt n’est pas présent :

true* : (not /EndInterrupt?) and /ExitInterrupt! → faux



• ExitInterrupt n’est jamais émis lorsque l’on n’est pas en modeinterruption :

true* : /ExitInterrupt! : (not /EnterInterrupt!)* : /ExitInterrupt! → faux

2.3.5.2. Le module SysMode

Rôle

Ce module a pour objet d’avertir le thread courant des interruptions logicielleset exceptions qui se produisent. Le processeur détecte l’occurrence d’un telévénement, mais il faut savoir à qui l’attribuer. En effet l’exécution d’ungestionnaire d’interruption logicielle fait passer le thread qui l’a initié en modesystème, s’il était en mode utilisateur. D’autre part, en mode traitementd’interruption matérielle, ces événements ne font pas passer en mode système,puisque l’on s’y trouve déjà.

Le module SysMode transmet donc le signal d’interruption ou d’exception authread courant, qu’il détermine grâce à une variable partagée avec l’ordonnanceur,sauf lorsque l’on est en train de traiter une interruption matérielle.

Interface


Trap integer E matériel; interruption logicielle

TrapRet E gestionnaire d’interruption; fin detraitement

Exception integer E matériel; exception

ExceptionRet E gestionnaire d’exception; fin detraitement

EnterInterrupt E InterruptMgr ; entrée en modeinterruption

ExitInterrupt E InterruptMgr ; sortie du modeinterruption

ThreadTrap S composant Thread courant;redirection de Trap

ThreadTrapRet S composant Thread courant;redirection de TrapRet

ThreadException S composant Thread courant;redirection de Exception

ThreadExceptionRet S composant Thread courant;redirection de ExceptionRet

Vérifications

Le graphe de cet automate étant simple, nous le donnons ici en totalité :



ExceptionRet?.ThreadExceptionRet!

TrapRet?.ThreadTrapRet!

Exception?.ThreadException!

Trap?.ThreadTrap!

EnterInterrupt?

ExitInterrupt?

1 2

Graphe d’états complet

Etat 1 : Un thread s’exécuteEtat 2 : Un gestionnaire d’interruption matérielle s’exécute

Nous voyons clairement le comportement de ce module : tant que l’on n’est pasen mode interruption (état 2), il se contente de rediriger les signaux de début et find’exception/trappe vers le thread courant. Lorsque le signal EnterInterrupt estreçu, le module devient silencieux jusqu’à réception de ExitInterrupt .

Cette dernière propriété est l’objet de ce module, elle assure que l’onn’attribuera pas une trappe ou une exception à un thread alors que l’on traite uneinterruption. Cette méprise, si elle se produisait, pourrait faire passer en modesystème un thread qui n’a rien fait pour. Nous vérifions formellement que cela nepeut pas se produire, en prouvant que les signaux Thread* ne peuvent être émis sion est entré en mode interruption (/EnterInterrupt?) et que l’on n’en est pas sorti(not /ExitInterrupt?). Ceci s’exprime à l’aide des actions abstraites suivantes :

true* : /EnterInterrupt? : (not /ExitInterrupt?)* : (not /ExitInterrupt?) and (/ThreadTrap! or /ThreadTrapRet! or/ThreadException! or /ThreadExceptionRet!) → faux

D’autre part, l’inverse doit aussi être rendu impossible : un thread qui provoqueune trappe ou une exception doit toujours en être averti par ce module. Ceci sevérifie pour chaque événement (nous ne le montrons ici que pour Trap ), endémontrant qu’il est toujours réemis lorsque l’on n’est pas en mode interruption,c’est-à-dire (i) si l’on n’a jamais reçu le signal EnterInterrupt , ou (ii) si l’on ne l’apas reçu depuis la dernière occurrence de ExitInterrupt :

(i) ((not /EnterInterrupt?)*+

(ii) (true* : /ExitInterrupt? : (not /EnterInterrupt?)*)): /Trap? and not /ThreadTrap! → faux

2.3.6. La gestion du temps : composant TimeMgr

Ce composant est constitué de deux modules : l’un s’occupe du traitement del’interruption horloge, il est stimulé par le module InterruptMgr , qui l’avertit de



l’occurrence d’une interruption horloge, l’autre, TimerMgr , gère les demandes detimers des threads.

NextTimeOutNoTimer

ClockTick

TimerOut

SetTimerDelTimer

TimeGuard TimerMgr

Relations entre les modules du composant Time

2.3.6.1. Gestion des timers : module TimerMgr

Rôle

Chaque thread peut programmer un timer pour que lui soit signalé uneéchéance temporelle. Le rôle du module TimerMgr est de maintenir une liste destimers programmés par l’ensemble des threads du système, et de déterminer leprochain qui arrivera à expiration, s’il y en a au moins un. Il avertit alors lemodule de gestion de l’interruption horloge TimeGuard de sa date.

La gestion des structures de données nécessaires à cette gestion est bien sûrécrite dans un langage externe.

Interface


SetTimer TimerParam E application, composant système; etcomposant Thread ; ajout d’un nouveautimer

DelTimer TimerParam E application, composant système, etcomposant Thread ; suppression d’un timeren cours

NextTimeOut TimeVal module TimeGuard ; nouvelle date duprochain timer

NoTimer S module TimeGuard ; plus de timer enattente

TimeVal est une date.

TimerParam est le paramètre du timer, il contient la date à laquelle le timerdoit expirer, et la référence de l’événement qu’il doit produire lors de sonexpiration.



2.3.6.2. Gestion de l’interruption horloge : module TimeGuard

Rôle du module

Nous souhaitons intégrer la modélisation de la gestion du temps à notresystème, afin de pouvoir disposer des outils pour effectuer des contrôles temporels.Pour cela nous écrivons un module de traitement de l’interruption horloge,TimeGuard , s’inspirant de celui de CHORUS. Ce module a pour mission :

• de maintenir une date courante, qui est un entier incrémenté à chaque tickd’horloge;

• de lancer les gestionnaires de timers arrivant à expiration (signal sortantTimerOut ).

Interface


ClockTick E composant Interrupt ; interruptionhorloge

NextTimeOut TimeVal E module TimerMgr ; nouvelle date duprochain timer

NoTimer E module TimerMgr ; plus de timer enattente

TimerOut TimerParamList S le destinataire est un paramètre dutimer, TimerOut en contient une liste;signale l’expiration d’au moins un timer

TimerParam est le paramètre du timer, il contient la date à laquelle le timerdoit expirer, et la référence de l’événement qu’il doit produire lors de sonexpiration.

TimerParamList est, comme son nom l’indique, une liste de TimerParam . Lorsde l’occurrence du signal TimerOut , la procédure externe qui le traitera doitémettre individuellement chaque signal référencé dans cette liste.

Vérifications

La seule action externe de ce module est l’émission du signal TimerOut ,signalant l’expiration d’un timer programmé. Les vérifications à faire portent doncsur les occurrences de ce signal, qui doit d’une part ne pas rater d’expiration detimer, et d’autre part ne pas en signaler intempestivement. Les informationspermettant de décider de l’expiration d’un timer étant partiellement cachées àl’automate, sous forme de données (la date courante, la valeur du signalNextTimeOut , la liste des timers en attente...), il n’est pas possible de faireformellement l’ensemble des vérifications que l’on souhaiterait. Toutefois certainscomportements erronés peuvent être certifiés impossibles.



Le premier concerne l’assurance de la continuité du service de ce module, car ilne possède pas d’état puits.

Concernant les émissions intempestives de TimerOut , on vérifie qu’il ne peutêtre émis, lorsqu’il n’y a plus de timer en attente, tant qu’un nouveau timer n’a pasété programmé. Cela se traduit formellement en exprimant que si le signalNoTimer est reçu, alors on est sûr que l’on n’émettra pas TimerOut tant qu’unnouveau NextTimeOut ne sera pas arrivé :

true* : /NoTimer? : (not /NextTimeOut?)* : (not /NextTimeOut?) and TimerOut! → faux

Cette vérification ne concerne que les situations où il y a eu des timers, qui onttous soit expiré, soit été annulés. Il faut la compléter par la suivante, qui assureque TimerOut ne peut être émis tant que l’on n’a pas reçu au moins unNextTimeOut :

(not /NextTimeOut?)* : (not /NextTimeOut?) and /TimerOut! → faux

2.3.7. Les états d’un thread : Composant Thread

Chaque thread géré par le système a son état maintenu par un composantThread . Globalement cela consiste à indiquer à l’ordonnanceur si le thread est prêtà s’exécuter ou non. Cet état est en fait décomposé en un ensemble de sous-états,conformément à ce que nous avons présenté au paragraphe 2.2.2.1 : le thread peut-être suspendu, arrêté, endormi, en mode système, ou bien dans une combinaisonde ces sous-états. Chacun d’eux est géré par un module particulier, le modulethMain réunissant ses informations pour en déduire l’état global du thread.

thTrapExc thStop thSleepthSuspend

BeReadyStopBeUnReadyStop

BeReadySuspendBeUnReadySuspend

BeReadySleepBeUnReadySleep

StopStartMaskStopUnMaskStopDeleteThread

SuspendResumeMaskSuspendUnMaskSuspendDeleteThread

SleepAwakeAbortMaskAbortUnMaskAbortDeleteThread

TrapTrapRetExceptionExceptionRet

EnterSystemModeExitSystemMode

MaskDeleteUnMaskDeleteDeleteThread

thMain

ActiveBlockedFree

AwakenSetTimerDelTimer

Relations entre les modules du composant Thread



2.3.7.1. Gestion des suspensions : module thSuspend

Rôle

L’état de suspension d’un thread est géré par ce module, qui traite aussi lemasquage/démasquage de ce type de blocage. Une constante, passé en paramètrede création de ce module, indique si le thread doit être créé dans l’état suspenduou actif. Toute demande de destruction de thread fait quitter l’état suspendu, sil’on s’y trouvait. Le module ne peut alors plus passer dans cet état, il attendpassivement sa destruction.

Pour indiquer l’entrée et la sortie de l’état suspendu, le module thSuspend émetrespectivement les signaux BeUnReadySuspend et BeReadySuspend .

Interface


Suspend E application; incrémente le compteur desuspension du thread

Resume E application; décrémente le compteur desuspension du thread

MaskSuspend E composant système; masquage de l’opérationSuspend

UnMaskSuspend E composant système; démasquage de l’opérationSuspend

DeleteThread E application; demande de destruction du thread

BeReadySuspend S module thMain ; le thread quitte l’étatsuspendu

BeUnReadySuspend S module thMain ; le thread devient suspendu

Vérifications

Cet automate, comme la plupart des autres modules de contrôle des threads,possède un état puits, accessible uniquement si l’on a reçu le signal DeleteThread ,auquel cas il est normal qu’il n’accepte plus de commande.

Les conditions d’entrée et de sortie de l’état suspendu dépendent du compteurde suspension géré par ce module, il n’est donc pas possible d’exprimerformellement toutes les situations dans lesquelles se trouve ce module. Toutefoison veut vérifier que certains comportements, qui généreraient une erreur, nepeuvent pas se produire.

En premier lieu, nous voulons nous assurer qu’il n’est pas possible qu’un threadsoit à la fois suspendu et non suspendu, ce qui n’aurait pas de sens pourl’ordonnanceur. Nous vérifions donc que les signaux BeReadySuspend etBeUnReadySuspend sont exclusifs :

true* : /BeReadySuspend! and /BeUnReadySuspend! → faux



On veut vérifier les conditions d’émission de BeUnReadySuspend , qui doivent serésumer à deux situations : sur réception de Suspend , et sur réception deUnMaskSuspend si on a reçu auparavant MaskSuspend puis Suspend . L’actionabstraite suivante, exprimant que le thread passe à l’état suspendu alorsqu’aucune des deux situations ne s’est produite, est garantie impossible pourl’automate :

true* : (not /Suspend? and not /UnMaskSuspend?) and /BeUnReadySuspend!→ faux

Nous nous intéressons maintenant au fonctionnement du masquage de lasuspension. Le premier point essentiel à vérifier est qu’il est impossible de passerà l’état suspendu alors que cette opération est masquée :

true* : /MaskSuspend and not /UnMaskSuspend? : ((not /UnMaskSuspend?) or /MaskSuspend?)* : (not /UnMaskSuspend?) and BeUnReadySuspend! → faux

Cette action teste la situation où la demande de suspension se produit alors quel’opération est masquée. Il faut aussi nous assurer que le masquage est efficaceimmédiatement, c’est-à-dire même s’il est simultané avec la demande desuspension :

true* : /MaskSuspend and not /UnMaskSuspend? : ((not /UnMaskSuspend?) or /MaskSuspend?)* : (not /UnMaskSuspend?) and BeUnReadySuspend! → faux

2.3.7.2. Gestions des arrêts : module thStop

Rôle

L’état d’arrêt d’un thread est géré par ce module, qui traite aussi lemasquage/démasquage de ce type de blocage. Toute demande de destruction dethread fait quitter l’état d’arrêt, si l’on s’y trouvait. Le module ne peut alors pluspasser dans cet état, il attend passivement sa destruction.

Pour indiquer l’entrée et la sortie de l’état d’arrêt, le module thStop émetrespectivement les signaux BeUnReadyStop et BeReadyStop .

Interface


Stop E application; demande l’arrêt du thread

Start E application; demande le redémarrage du thread

MaskStop E composant système; masquage de l’opération Stop

UnMaskStop E composant système; démasquage de l’opérationStop


BeReadyStop S module thMain ; le thread quitte l’état d’arrêt



BeUnReadyStop S module thMain ; le thread devient d’arrêt

Vérifications

Ce module assure une fonction semblable à celle de thSuspend , un certainnombre de vérifications nécessaires sont donc directement repoduites de cemodule : exclusion entre les signaux BeReadyStop et BeUnReadyStop , impossibilitéde bloquer le thread si ce blocage est masqué, accession à un état puits lors de laréception de DeleteThread , et liste définie de signaux pouvant provoquer leblocage. Nous ne détaillons pas de nouveau ces vérifications.

Les conditions de blocage d’un thread par arrêt, contrairement à la suspensionqui utilise une variable, sont entièrement déterminées par l’automate. Nous allonsdonc pouvoir vérifier précisément les situations pouvant amener à un changementd’état.

Nous savons (cf. premier paragraphe) que seuls les signaux Stop et UnMaskStop

peuvent bloquer le thread. Examinons maintenant les conditions dans lesquellesils le font. Nous allons tout d’abord montrer que Stop bloque toujours le thread s’ilest dans un état déterminé : non arrêté, avec arrêt non masqué. Cet état estcomplexe, car il déterminé par deux sous-états, qui peuvent être atteints dans unordre quelconque :

• Etat non arrété : Soit le thread n’a jamais été arrété (il n’a jamais émisBeUnReadyStop ), soit il a redémarré (il a reçu BeReadyStop , et aucunBeUnReadyStop depuis).

• Etat non masqué : Il faut noter que la présence simultanée de MaskStop etUnMaskStop n’a aucun effet sur l’état du thread, car ces deux signauxs’annulent. Ainsi le passage à l’état masqué se produit lorsque MaskSuspend

est présent sans UnMaskSuspend , et le démasquage se produit lors del’occurrence de UnMaskSuspend sans MaskSuspend . Le thread est dans l’étatnon maqué s’il n’a jamais été masqué, ou bien s’il a été démasqué depuis.

L’action abstraite suivante reprend ces différentes situations, le symbole “+”permettant de définir les alternatives non seulement des signaux pouvant mener àl’état désiré, mais les ordres possibles dans lesquels ils peuvent se produire. Ladernière ligne spécifie la situation que nous voulions vérifier, c’est-à-dire quel’occurrence de Stop , sans Start ni masquage, ne peut pas ne pas produireBeUnReadyStop :

( ((not /MaskStop? or /UnMaskStop?)* : /BeReadyStop! and (not /MaskStop? or /UnMaskStop?))

+ ((not /MaskStop? or /UnMaskStop?) and not /BeUnReadyStop!)*

+ ((not /BeUnReadyStop!)* : (not /BeUnReadyStop!) and (/UnMaskStop? and not /MaskStop?))



+ (true* : ( (/BeReadyStop! and (/UnMaskStop? and not /MaskStop?)) + (/BeReadyStop! : (not /BeUnReadyStop!)* : (not /BeUnReadyStop!) and (/UnMaskStop? and not /MaskStop?)) + ((/UnMaskStop? and not /MaskStop?) : (not /MaskStop? or /UnMaskStop?)* : (not /MaskStop? or /UnMaskStop?) and /BeReadyStop!) ) ) ) : ((not /MaskStop? or /UnMaskStop?) and not /BeUnReadyStop!)* : /Stop? and not /Start? and (not /MaskStop? or /UnMaskStop?) and not/BeUnReadyStop!

→ faux

Nous voulons ensuite vérifier ce qui se passe lorsqu’un arrêt est demandépendant un masquage. Nous voulons nous assurer que l’arrêt sera différé jusqu’audémasquage. Nous savons déjà que le blocage ne se produit pas au moment dumasquage (cf. premier paragraphe), il nous faut donc vérifier que l’arrêt est effectifà la sortie du démasquage. Nous utilisons encore une fois l’alternative “+”, pourexprimer que l’arrêt peut être demandé au moment du masquage, ou bien après :

( (true* : /BeReadyStop!) + (not /BeUnReadyStop!)* ) : ((/MaskStop? and (not /UnMaskStop?) and /Stop? and not /Start?) + (/MaskStop? and not /UnMaskStop? : ((not /UnMaskStop?) or /MaskStop?)* : (((not /UnMaskStop?) or /MaskStop?) and not /Start?) and /Stop? )) : (((not /UnMaskStop?) or /MaskStop?) and not /Start?)* : /UnMaskStop? and (not /MaskStop?) and not /Start? and not /BeUnReadyStop!

→ faux

Nous avons examiné les conditions de blocage, étudions maintenant celles dudéblocage. Le module sort de l’état d’arrêt en émettant le signal BeReadyStop , lorsde l’occurrence de DeleteThread ou Start . La première équation permet devérifier que BeReadyStop n’est émis que si l’un de ces deux signaux est présent, ladeuxième qu’il est émis à chaque fois que l’un des deux est présent si le threadétait à l’arrêt :

true* : (not /DeleteThread?) and (not /Start?) and (/BeReadyStop!) → faux

true* : /BeUnReadyStop! : (not /DeleteThread? and (not /Start? or /Stop?))* : (/DeleteThread? or (/Start? and not /Stop?)) and (not /BeReadyStop!) → faux



2.3.7.3. Gestion des attentes : module thSleep

Rôle

Le module thSleep gère les attentes d’événements des threads. A chaqueattente est associée une échéance, dont la mémorisation est assurée par l’envoi dusignal SetTimer au composant Time , afin qu’il arme un timer. Ce composant,arrivé à l’échéance, émet le signal TimeOut , ce qui provoque la sortie de l’étatd’attente, et l’émission du signal Awaken avec une valeur identifiant ce type deréveil.

Les autres causes de réveil sont l’occurrence de l’événement attendu, s’il y en aun, et l’annulation d’attente, qui sont elles aussi identifiées par la valeur du signalAwaken. Lorsqu’un de ces deux événements se produit avant l’échéance, le signalDelTimer est émis pour annuler le timer qui avait été programmé.

Contrairement aux deux modules précédents, ce n’est pas ici la fonction deblocage que l’on peut masquer, mais celle d’annulation des attentes. Un compteurest associé à cette fonction, mémorisant le nombre d’attentes à annuler. Lorsquel’on demande une annulation, s’il n’y a pas d’attente en cours ou si les annulationssont masquées, le compteur est incrémenter. Lorsqu’une attente est demandée, sice compteur est supérieur à zéro et que les annulations ne sont pas masquées,alors l’attente est abandonnée.

Toute demande de destruction de thread provoque l’annulation de l’attente encours, s’il y en a une.

Pour indiquer l’entrée et la sortie de l’état d’attente, le module thSleep émetrespectivement les signaux BeUnReadySleep et BeReadySleep .

Interface


Sleep E application; demande la mise en attente duthread

Awake E application; réveil du thread sur événementattendu

TimeOut E application; réveil du thread sur expiration del’échéance de l’attente

Abort E application; réveil du thread sur annulation del’attente

MaskAbort E composant système; masquage de l’opérationAbort

UnMaskAbort E composant système; démasquage de l’opérationAbort


Awaken integer S application; informe du réveil du thread et desa cause

SetTimer integer S composant Time ; programmation d’un timer



DelTimer S composant Time ; annulation d’un timer

BeReadySleep S module thMain ; le thread quitte l’état d’attente

BeUnReadySleep S module thMain ; le thread devient en attente

Vérifications

Comme pour les deux modules précédents, des vérifications de base sont faites,que nous ne reproduisons pas ici : exclusion entre BeReadySleep etBeUnReadySleep , accession à un état puits lors de la réception de DeleteThread .Le seul signal pouvant provoquer le passage à l’état d’attente est ici Sleep . Lemasquage dans ce module concerne l’annulation, et non le blocage comme dans lesmodules précédents.

Le graphe complet de l’automate comporte 3 états et 46 transitions, ce qui lerend totalement illisible. Pour s’en convaincre, en voici une miniaturisation :

Abort#.Awake#.DeleteThread#.MaskAbort#.TimerOut#.UnMaskAbort#

Abort?.Awake#.DeleteThread#.MaskAbort#.TimerOut#.UnMaskAbort#

Abort?.Awake#.DeleteThread#.MaskAbort#.TimerOut#.UnMaskAbort#.Awaken!.BeReadySleep!.DelTimer!TimerOut?.Awake#.DeleteThread#.MaskAbort#.UnMaskAbort#.Awaken!.BeReadySleep!

Awake?.DeleteThread#.MaskAbort#.UnMaskAbort#.Awaken!.BeReadySleep!.DelTimer!

UnMaskAbort?.Abort#.Awake#.DeleteThread#.MaskAbort#.TimerOut#

Abort?.UnMaskAbort?.Awake#.DeleteThread#.MaskAbort#.TimerOut#

Abort?.UnMaskAbort?.Awake#.DeleteThread#.MaskAbort#.TimerOut#.Awaken!.BeReadySleep!.DelTimer!TimerOut?.UnMaskAbort?.Awake#.DeleteThread#.MaskAbort#.Awaken!.BeReadySleep!Awake?.UnMaskAbort?.DeleteThread#.MaskAbort#.Awaken!.BeReadySleep!.DelTimer!

MaskAbort?.Abort#.Awake#.DeleteThread#.TimerOut#.UnMaskAbort#

Abort?.MaskAbort?.Awake#.DeleteThread#.TimerOut#.UnMaskAbort#

Abort?.MaskAbort?.Awake#.DeleteThread#.TimerOut#.UnMaskAbort#.Awaken!.BeReadySleep!.DelTimer!MaskAbort?.TimerOut?.Awake#.DeleteThread#.UnMaskAbort#.Awaken!.BeReadySleep!

Awake?.MaskAbort?.DeleteThread#.UnMaskAbort#.Awaken!.BeReadySleep!.DelTimer!

MaskAbort?.UnMaskAbort?.Abort#.Awake#.DeleteThread#.TimerOut#

Abort?.MaskAbort?.UnMaskAbort?.Awake#.DeleteThread#.TimerOut#

Abort?.MaskAbort?.UnMaskAbort?.Awake#.DeleteThread#.TimerOut#.Awaken!.BeReadySleep!.DelTimer!MaskAbort?.TimerOut?.UnMaskAbort?.Awake#.DeleteThread#.Awaken!.BeReadySleep!Awake?.MaskAbort?.UnMaskAbort?.DeleteThread#.Awaken!.BeReadySleep!.DelTimer!

DeleteThread?.Awaken!.BeReadySleep!.DelTimer!

MaskAbort?.Abort#.Sleep#.UnMaskAbort#

MaskAbort?.UnMaskAbort?.Abort#.Sleep#

Sleep?.Abort#.MaskAbort#.UnMaskAbort#.BeUnReadySleep!.SetTimer!

Sleep?.Abort#.MaskAbort#.UnMaskAbort#.Awaken!

Sleep?.UnMaskAbort?.Abort#.MaskAbort#.BeUnReadySleep!.SetTimer!

Sleep?.UnMaskAbort?.Abort#.MaskAbort#.Awaken!

MaskAbort?.Sleep?.Abort#.UnMaskAbort#.BeUnReadySleep!.SetTimer!

MaskAbort?.Sleep?.Abort#.UnMaskAbort#.Awaken!

MaskAbort?.Sleep?.UnMaskAbort?.Abort#.BeUnReadySleep!.SetTimer!

MaskAbort?.Sleep?.UnMaskAbort?.Abort#.Awaken!

Abort?.MaskAbort#.Sleep#.UnMaskAbort#

Abort?.Sleep?.MaskAbort#.UnMaskAbort#.BeUnReadySleep!.SetTimer!

Abort?.Sleep?.MaskAbort#.UnMaskAbort#.Awaken!Abort?

.UnMaskAbort?

.MaskAbort#.Sleep#

Abort?.Sleep?.UnMaskAbort?.MaskAbort#.BeUnReadySleep!.SetTimer!

Abort?.Sleep?.UnMaskAbort?.MaskAbort#.Awaken!

Abort?.MaskAbort?.Sleep#.UnMaskAbort#

Abort?.MaskAbort?.Sleep?.UnMaskAbort#.BeUnReadySleep!.SetTimer!

Abort?.MaskAbort?.Sleep?.UnMaskAbort#.Awaken!

Abort?.MaskAbort?.UnMaskAbort?.Sleep#

Abort?.MaskAbort?.Sleep?.UnMaskAbort?.BeUnReadySleep!.SetTimer!

Abort?.MaskAbort?.Sleep?.UnMaskAbort?.Awaken!

3 2

1

Nous allons en extraire deux réductions afin d’en étudier des comportementsn’impliquant qu’un nombre limité de signaux.



Nous allons examiner les conditions d’émission du signal Awaken. Nous voulonsnous assurer que le signal Awaken ne sera pas émis alors que le thread est bloquéen attente d’un événement, ce qui serait incohérent. Une réduction du graphe nouspermet de constater qu’il est émis soit sur occurrence de BeReadySleep , et àcondition que l’on ait émis BeUnReadySleep avant (on était donc dans l’étatd’attente), soit alors que l’on était réveillé (c’est le cas d’une demande de délainul) :

BeUnReadySleep!

Awaken!

Awaken!.BeReadySleep!

1 3

Graphe réduit sur les signaux BeUnReadySleep , BeReadySleep et Awaken.

Etat 1 : Pas d’attente en coursEtat 3 : Le thread est bloqué en attente d’un événement

Ceci se démontre formellement en montrant que l’action abstraite suivante estimpossible :

(true*: /BeUnReadySleep!: (not /BeReadySleep!)* : /Awaken! and not /BeReadySleep!) + (true*:/BeUnReadySleep!:(not /BeReadySleep!)* : /Awaken! and not /BeReadySleep!)→ faux

Nous devons aussi vérifier que la programmation des timers est correcte : touttimer programmé doit être annulé, à moins qu’il n’ait expiré. Ceci est vérifié àl’aide d’une autre réduction du graphe :

SetTimer!

TimerOut?

DelTimer!

1 3

Graphe réduit sur les signaux SetTimer , DelTimer et TimerOut .

Etat 1 : Pas d’attente en coursEtat 3 : Le thread est bloqué en attente d’un événement



Vérifier ce comportement revient à montrer que le thread ne peut pas êtreréveillé avec un timer en cours : il doit être annulé, à moins qu’il n’ait expiré :

true*: /BeUnReadySleep! and /SetTimer!: (not /BeReadySleep!)*: /BeReadySleep! and (not /TimerOut? and not /DelTimer!);→ faux

2.3.7.4. Gestions de l’état global : module thMain

Rôle

Chacun des modules précédents gère un sous-état de blocage. Le modulethMain collecte les informations relatives à l’entrée et la sortie de ces sous-états,afin de déterminer l’état global du thread. Le thread est prêt s’il n’est dans aucunsous-état de blocage, sinon il est bloqué. En sortie, thMain informe l’ordonnanceurde cet état.

Ce module prend en paramètre d’initialisation la même constante quethSuspend , lui indiquant si le thread est créé dans l’état actif ou non. S’il l’est,thMain émet le signal Active dès sa première réaction.

Lorsqu’une destruction du thread est demandée, c’est thMain qui transmetcette demande à l’ordonnanceur, si la destruction n’est pas masquée.

Interface



MaskDelete E composant système; masquage de l’opérationDeleteThread

UnMaskDelete E composant système; masquage de l’opérationDeleteThread

BeReadySuspend E module thSuspend ; le thread quitte l’étatsuspendu

BeUnReadySuspend E module thSuspend ; le thread devient suspendu

BeReadyStop E module thStop ; le thread quitte l’état d’arrêt

BeUnReadyStop E module thStop ; le thread devient arrêté

BeReadySleep E module thSleep ; le thread quitte l’étatd’attente

BeUnReadySleep E module thSleep ; le thread devient en attente

Active S module Scheduler ; le thread passe à l’état prêt

Blocked S module Scheduler ; le thread passe à l’étatbloqué

Free S module Scheduler ; le thread se suicide

Vérifications

L’automate de ce module possède un état puits, qui correspond à l’état en coursd’effacement. Dans cet état, le thread ne fait rien, il attend d’être détruit par



l’ordonnanceur. Un examen des chemins permettant d’accéder à cet état montrequ’ils contiennent tous la réception du signal DeleteThread et l’émission de Free .

Les deux fonctions de ce module concernent la gestion de l’état global du threadet celle de sa destruction. Nous allons examiner les comportements associés à cesfonctions.

La gestion de l’état global du thread consiste à émettre les signaux Active etBlocked . Tout d’abord on vérifie qu’Active n’est émis que sur occurrence d’unsignal BeReady* , ce que garantie l’inaccessibilité de l’action abstraite suivante :

not /BeReadyStop? and not /BeReadySleep? and not /BeReadySuspend? and /Active!

→ faux

Le signal Active doit être émis uniquement si on n’a reçu aucun BeUnReady*

depuis le BeReady* correspondant. Les thread étant toujours créés dans l’étatsuspendu, un test particulier est utilisé pour BeReadySuspend/BeUnReadySuspend .

( (true*:/BeUnReadySleep?:(not /BeReadySleep?)*) + (true*:/BeUnReadyStop?:(not /BeReadyStop?)*) + ((true*:/BeUnReadySuspend?:(not /BeReadySuspend?)*)+(not /BeReadySuspend?)*) ): (not /BeReadySleep?) and (not /BeReadyStop?) and (not /BeReadySuspend?) and/Active?

→ faux

Enfin, on vérifie que la sortie du dernier sous-état bloqué provoque toujoursl’émission d’Active . Nous allons pour cela faire apparaître à l’interface externe dumodule des signaux qui sont internes : readySuspend , readySleep , readyStop , quisont toujours présents tant que le thread n’est pas, respectivement, suspendu,endormi ou arrêté. La validité de ces signaux est facilement démontrable. Nous neprésentons ici que le cas où l’arrêt est la seule raison de blocage (readyStop est leseul absent des trois signaux), et nous montrons que la fin de cet arrêt provoquetoujours l’émission du signal Active . La vérification est identique pour les deuxautres cas de blocage.

true*:(not /readyStop! and /readySuspend! and /readySleep!):/BeReadyStop? and not /BeUnReadySleep? and not /BeUnReadySuspend? and not/Active!

→ faux

La vérification du comportement du signal Blocked se fait en trois étapes, defaçon semblable à celle d’Active : on s’assure tout d’abord qu’il ne peut êtreprésent que si au moins un signal BeUnReady* est présent, puis qu’il ne peut pasêtre présent si au moins au moins un des signaux ready* est présent, et enfin qu’il



doit être présent si aucun de ces trois signaux n’est présent. Nous ne présentonspas ici ces vérifications.

Examinons maintenant le comportement de la destruction du thread. Vérifionstout d’abord que Free ne peut pas être émis (donc l’état puits ne peut pas êtreatteint) si l’opération d’effacement est masquée, c’est-à-dire si MaskDelete a étéreçu mais pas UnMaskDelete .

true* : /MaskDelete? and not /UnMaskDelete? : (not /UnMaskDelete?)* : not /UnMaskDelete? and /Free! → faux

Lors d’un démasquage, si le signal DeleteThread a été reçu alors on doitémettre Free . Il faut d’une part vérifier à chaque masquage ou démasquage quel’opération inverse n’a pas eu lieu simultanément, et d’autre part s’assurer qu’il n’ya pas eu de DeleteThread avant la condition finale. Le “+” permet d’exprimerl’alternative entre la situation où le démasquage à lieu en même temps quel’effacement et celle où elle a lieu après :

true* : /MaskDelete? and not /DeleteThread? : (not /UnMaskDelete? and not /DeleteThread?)* : ((/DeleteThread? and /UnMaskDelete? and not /Free!) + (/DeleteThread? : (not /UnMaskDelete?)*) : /UnMaskDelete? and not /Free!)→ faux

2.3.7.5. Gestions du mode d’exécution : module thTrapExc

Rôle

Le module thTrapExc a pour mission de déterminer le mode d’exécution duthread. Pour cela il dispose d’une constante, paramètre d’initialisation, qui luiindique si le thread est créé en mode système, auquel il y restera toujours, ou s’ilest en mode utilisateur. Dans ce cas, thTrapExc surveille les interruptionslogicielles et exceptions qui se produisent pendant l’exécution du thread. Lorsqu’unde ces deux événements se produit, le thread passe en mode système, jusqu’à cequ’il y ait eu autant de sortie que d’entrée dans ce mode.

Le module signale l’entrée et la sortie du mode système par l’émission deEnterSystemMode et ExitSystemMode .

Interface


Trap integer E composant Interrupt ; le thread a provoquéune interruption logicielle

TrapRet E composant Interrupt ; le thread sort d’uneinterruption logicielle

Exception integer E composant Interrupt ; le thread a généré uneexception



ExceptionRet E composant Interrupt ; le thread sort d’uneexception

EnterSystemMode S composant Scheduler ; le thread passe enmode système

ExitSystemMode S composant Scheduler ; le thread quitte lemode système

Vérifications

Voici le graphe complet de l’automate, qui aide à la compréhension ducomportement de ce module :

Exception?.EnterSystemMode!

Trap?.EnterSystemMode!

EnterSystemMode!

ExceptionRet?ExceptionRet?.ExitSystemMode!

TrapRet?

TrapRet?.ExitSystemMode!

Exception?

Trap?

3

1

2

4

Graphe d’états complet

Etat 1 : Etat initialEtat 2 : Le thread est créé en mode système, il y restera toujoursEtat 3 : Le thread est en mode utilisateur (il a été créé dans ce mode)Etat 4 : Le thread est provisoirement en mode système

Le graphe possède un état puits, qui correspond au cas où le module thTrapExc

est associé à un thread superviseur (c’est un paramètre de création du module), ilentre alors en mode système (émission de EnterSystemMode ) à sa création en n’ensort jamais.

Sinon, le thread est en mode utilisateur, il passe en mode système lorsqu’ilreçoit Trap ou Exception . Il en ressort (émission de ExitSystemMode ) lors d’uneoccurrence de TrapRet ou ExceptionRet .

Les deux signaux ne peuvent pas être présents simultanément, car on nepourrait pas déterminer l’état du thread. Cette exclusion entre les deux signauxest vérifiée par l’action abstraite suivante :

true* : /EnterSystemMode! and /ExitSystemMode! → faux



Examinons les conditions d’émissions de EnterSystemMode . Il ne peut être émisque lors de l’occurrence de Trap ou Exception, sauf dans le cas où le thread est crééen mode système. Nous vérifions donc ceci en précisant que nous nous intéressonsaux threads créés en mode utilisateur, c’est-à-dire que la première action ne doitpas être l’émission de EnterSystemMode :

not /EnterSystemMode!: true* : /EnterSystemMode! and not /Trap? and not /Exception?

→ faux

La condition pour l’émission de EnterSystemMode est soit d’être un threadsystème au moment de son initialisation, soit d’être un thread utilisateur, en modeutilisateur, et de recevoir Trap ou Exception . La première étant évidente, nous neprésentons ici que la vérification de la deuxième condition :

not /EnterSystemMode! : ( (not /EnterSystemMode!)* + (true*:/EnterSystemMode!:(not /ExitSystemMode!)*:/ExitSystemMode! :(not /EnterSystemMode!)*)):(/Trap? or /Exception?) and not /EnterSystemMode!→ faux

D’autre part, nous pouvons nous assurer que deux occurrences deEnterSystemMode sont toujours séparées par au moins une occurrence deExitSystemMode :

true* : /EnterSystemMode! : (not /ExitSystemMode!)* : /EnterSystemMode!→ faux

De la même façon, on vérifie que ExitSystemMode ne peut être émis que siTrapRet ou ExceptionRet est présent, et que deux de ses occurrences sont toujoursséparées par au moins une occurrence de EnterSystemMode . Nous ne présentonspar ces vérifications.

De nouvelles exceptions ou trappes peuvent se produire alors que le thread estdéjà en mode système, un compteur est alors incrémenter pour mémoriser lenombre de retours (TrapRet ou ExceptionRet ) à attendre pour sortir du modesystème. La valeur de cette variable n’étant pas prise en compte dans l’automate,nous ne pouvons pas définir formellement les conditions dans lesquelles le signalExitSystemMode doit être émis.

2.3.8. L’ordonnancement : composant Scheduler

Dans la modélisation de l’ordonnancement, nous voulons isoler son aspectgénérique, mais aussi lui donner les fonctionnalités de celui de CHORUS. Pour cela,nous divisons l’ordonnanceur en deux composants, l’un générique fournissant lesopérations de base, l’autre spécifique implantant une politique particulière. A titred’exemple, nous implantons la politique de temps partagé de CHORUS.



La politique d’élection de l’ordonnancement est avant tout un calcul et unegestion de structures de données. Elle sera donc écrite dans un langage externe (Cou C++). Par contre la gestion du temps partagée est un élément du contrôle del’ordonnancement, elle sera écrite en ESTEREL.

SchedBase

SchedMechanisms

SchedPolicy

TimeSlice

Générique Spécifique

traitementréactif

traitementde

données

Séparation ordonnancement générique/spécifique

Nous définissons un module synchrone pour traiter l’aspect générique(SchedBase ), faisant appel à une interface ‘externe’ pour accéder à la politiqued’élection (SchedPolicy ). Cette politique est écrite conformément à celle deCHORUS. Le module générique et la politique d’élection font appel à un ensemblede mécanismes communs à tout ordonnancement (SchedMechanisms ), qui traitentdes structures de données d’exécutions des threads (piles, identificateurs...). Nousréalisons un module indépendant pour gérer le temps partagé (TimeSlice ). Cemodule prend en considération le signal horloge, qui n’est pas présent dans lemodule générique, et produit des occurrences d’événements d’ordonnancement. Lamise en commun de ces deux modules nous donne un seul module, qui, compilé

Run

RunThreadCreatedThreadDeleted

ClockTickFreeBlocked

SchedBase TimeSlice

TestSchedule

CreateThreadUpdateThreadFreeActiveBlockedEnterInterruptExitInterrupt

Relations entre les modules du composant Scheduler



avec la politique d’élection externe, réalise l’ordonnancement tel qu’il existe dansCHORUS. Pour réaliser un autre ordonnancement, il suffirait de compiler le modulegénérique avec une autre politique et/ou un ou plusieurs modules gérant d’autresfonctionnalités.

2.3.8.1. Ordonnancement générique : module SchedBase

Rôle

L’ordonnanceur effectue deux tâches de base : la gestion des structures dedonnées et de contrôle des threads et le contrôle de l’attribution du processeur.

Il gère la création et la destruction des ressources nécessaires à la gestion desthreads, en particulier il instancie un module de contrôle Thread pour chaquenouveau thread, qu’il détruit à sa terminaison. Cette opération doit configurerl’environnement et les structures de communications de telle sorte que, parexemple, le signal Active , émis par le thread idThread , indiquant que ce threaddevient prêt, soit traduit en entrée de Scheduler par Active(idThread) , maisaussi que l’occurrence du signal TimerOut(TimerParamList) en sortie de TimeMgr

se manifeste par la présence de signaux TimerOut en entrée des threads référencésdans le paramètre.

Il gère un ‘ensemble’ (quelle que soit sa nature, e.g. liste ordonnée, pool...) dethreads prêts à s’exécuter, ce qui consiste à se mettre en réception des signauxActive(idThread) et Blocked(idThread) en provenance des modules Thread , etde mettre à jour une structure de données en conséquence, grâce à l’interfaceexterne décrite précédemment.

A chaque événement d’ordonnancement, il élit un thread, et si ce thread estdifférent de celui en cours, alors il effectue un changement de thread courant enémettant le signal Run(newThread) . Il y a toujours au moins un thread prêt (etdonc éligible), puisque un thread dummyThread (qui ne fait rien et est toujoursprêt) est créé au démarrage du système et n’est jamais détruit. A chaquechangement de thread courant, l’ordonnanceur sauvegarde dans la structure dedonnée du thread sortant son contexte, s’il n’a pas été effacé, et affecte le contexted’exécution avec le contexte du thread élu.

L’ordonnanceur reçoit les avis d’entrée (signal EnterInterrupt ) et de sortie(signal ExitInterrupt ) du mode interruption, en provenance du gestionnaired’interruptions. Entre ces deux événements, l’ordonnanceur ne modifie pasl’attribution du processeur, puisque ce dernier est utilisé par le traitementd’interruption. Si un événement qui aurait dû modifier l’attribution du processeurse produit pendant que l’on est dans le mode interruption, alors cette nouvelleattribution est mémorisée et sera effectuée lorsque l’on en sortira.



Interface


CreateThread ThreadDesc E application; demande de création d’unnouveau thread

UpdateThread ThreadRef E application; demande de destruction dethread

Free ThreadRef E module Thread ; avis de fin de thread

Active ThreadRef E module Thread ; un thread devient prêt às’exécuter

Blocked ThreadRef E module Thread ; un thread devientbloqué

EnterInterrupt E module InterruptMgr ; entrée dans lemode interruption

ExitInterrupt E module InterruptMgr ; sortie du modeinterruption

TestSchedule E/S module d’ordonnancement spécifique,mais aussi émis localement; demande deréordonnancement

Run ThreadRef S module Thread ; modifie l’allocation duprocesseur

ThreadCreated ThreadRef S application; compte rendu de la créationdu thread (retour de son identificateur)

ThreadDeleted ThreadRef S environnement; terminaison de ladestruction d’un thread

Les types utilisés sont :

ThreadRef : identificateur du thread

ThreadDesc : descripteur de thread, comportant les informations nécessaires àla politique d’ordonnancement pour décider de son exécution.

Vérifications

Nous allons tout d’abord regarder le comportement de l’ordonnanceur parrapport aux interruptions. Une des propriétés essentielles que ce module doitgarantir est que le processeur n’est plus attribué aux threads lorsque l’on est enmode interruption. Le graphe complet de l’automate comporte 5 états et 533transitions. Pour nous aider à comprendre le fonctionnement du module nous enfaisons une réduction :



EnterInterrupt?

EnterInterrupt?.ExitInterrupt?

EnterInterrupt?.ExitInterrupt?.Run!

Run!

ExitInterrupt?

ExitInterrupt?.Run!

1 4

Graphe réduit sur les signaux EnterInterrupt , ExitInterrupt et Run

Etat 1 : L’ordonnanceur alloue le processeur aux threadsEtat 4 : On est en mode interruption, le processeur n’est plus alloué aux threads

Dans l’état 4, le signal Run n’est plus émis tant que l’on ne sort pas du modeinterruption. Cette propriété est vérifiée par l’action abstraite suivante, quinécessite la relation d’exclusion entre EnterInterrupt et ExitInterrupt , vérifiéelors de l’analyse du module InterruptMgr :

true* : /EnterInterrupt? : (not /ExitInterrupt?)* : (not /ExitInterrupt?) and/Run!→ faux

Ce graphe permet aussi de vérifier que l’ordonnanceur est toujours prêt àréagir aux entrées et sorties du mode interruption : La présence deEnterInterrupt fait toujours passer dans le mode interruption, celle deExitInterrupt le fait quitter.

D’autre part, des vérifications non détaillées ici permettent de s’assurer que lescréations, destructions, mises à jour, et les changements d’état des threads sonttoujours pris en compte, quel que soit le mode d’exécution. Ces vérifications sontréalisées en vérifiant l’implication entre le signal étudié et sa conséquenceattendue. Par exemple, pour la création, on vérifie que ThreadCreated est toujoursprésent lors de l’occurrence de CreateThread :

true* : /CreateThread? and not /ThreadCreated! → faux

La deuxième fonction essentielle que doit assurer le module est leréordonnancement. Lorsqu’il est demandé alors que le processeur est en modeinterruption, il est différé jusqu’à la sortie de ce mode. Ceci est réalisé enréémettant la demande au moment de l’occurrence de ExitInterrupt . Si cetteréémission n’est pas effectuée, le réordonnancement risque de se produirebeaucoup plus tard, l’exécution d’un thread très prioritaire peut être inutilementdifférée, ou pire encore un thread qui se bloque peut conserver le processeur. Onvérifie donc que toute occurrence du signal TestSchedule entre l’entrée et lasortie du mode interruption est réémis à l’occurrence de ExitInterrupt .



true* : /EnterInterrupt? and not /TestSchedule! : (not /ExitInterrupt?)* : (not /ExitInterrupt?) and /TestSchedule! : (not /ExitInterrupt?)* : /ExitInterrupt? and not /TestSchedule! → faux

Il faut aussi tester le cas où la demande de réordonnancement se produit aumoment de l’entrée dans le mode interruption :

true* : /EnterInterrupt? and /TestSchedule! : (not /ExitInterrupt?)* : /ExitInterrupt? and not /TestSchedule! → faux

2.3.8.2. Gestion du temps partagé : module TimeSlice

Rôle

La gestion du temps partagée est réalisée par le module TimeSlice , qui se metà l’écoute de l’ordonnanceur générique pour être informée du thread en coursd’exécution. Lorsqu’un thread de priorité supérieure à 127 prend le processeur, illui est imparti une durée maximum d’exécution. Le module TimeSlice contrôlecette durée, et à son expiration invoque une opération de SchedPolicy pourmodifier les paramètres d’ordonnancement du thread courant. Elle émet alorsTestSchedule pour demander au module générique de lancer une nouvelleélection du thread courant, en prenant en compte les modifications qu’elle aapportées.

Interface


ClockTick E composant Interrupt ; interruption horloge

Free ThreadRef E module Thread ; un thread se détruit

Blocked ThreadRef E module Thread ; un thread devient bloqué

Run ThreadRef E module Thread ; un thread prend leprocesseur

TestSchedule S module SchedBase ; demande deréordonnancement

Vérifications

Nous allons vérifier que le module TimeSlice est toujours prêt à traiter lesignal Run. Pour cela nous examinons le graphe de l’automate. Il contient 4 états et65 transitions, nous en faisons une réduction afin de le rendre lisible :



TestSchedule!

Run?

Run?

Run?.TestSchedule!

Run?.TestSchedule!

Run?

Run?

1 3

Graphe réduit sur les signaux Run et TestSchedule

Etat 1 : Le thread n’a le processeur que pour un quantum de tempsEtat 3 : Le thread a le processeur sans limite de temps

L’automate se trouve dans l’état 1 lorsqu’il surveille la durée d’exécution d’unthread, auquel cas TestSchedule (signalant la fin d’un quantum) peut être émis.Dans l’état 3 il laisse le thread courant s’exécuter infiniment. Examinons lesconditions de passage de l’un à l’autre.

A chaque fois que le signal Run est émis, le nouveau thread qui prend leprocesseur peut soit être limité par un quantum de temps, soit être interruptibleuniquement par un thread plus prioritaire. Quelque soit l’état, l’occurrence de Run

peut donc amener à l’état 1 ou 3.

Lorsque TestSchedule est émis, le module SchedBase peut déciderinstantanément de changer l’attribution du processeur, cet événement semanifeste par la présence simultanée des deux signaux TestSchedule!.Run? . SiTestSchedule est émis seul, cela indique que SchedBase a décidé de laisser leprocesseur au thread malgré l’expiration de son quantum. Dans ce cas on passe àl’état 3 car il n’est plus nécessaire de surveiller le temps d’exécution du thread.L’action abstraite suivante nous permet de garantir de comportement :

true* : /TestSchedule! and not /Run? : (not /Run?)* : /TestSchedule! →faux

La transition de l’état 1 à 3 sans label est dû aux signaux non pris en comptedans cette réduction, c’est-à-dire Blocked et Free . En effet lorsque le threadcourant quitte de lui même le processeur (forcément par un de ces deux signaux) etque Run n’est pas émis (c’est le cas pendant le traitement des interruptions), il nefaut plus surveiller le temps d’exécution. Ceci ne peut pas être directement vérifié,car le comportement dépend des valeurs des signaux Free et Blocked , quicontiennent la référence des threads concernés. Par contre, il est possible d’ajouterdes signaux, dans la phase de vérification, pour informer de l’occurrence de



certaines situations. Par exemple, nous rajoutons ici un signal EndQuantum , émis àchaque fois que les signaux Free et Blocked contiennent la référence du threadsurveillé. On peut alors faire notre vérification :

true* : /EndQuantum! and not /Run? : (not /Run?)* : /TestSchedule! →faux

2.3.9. Récapitulatif

Voici regroupé dans un schéma la structure générale de notre gestion destâches. Certaines simplifications y ont été apportées, afin de ne pas le surcharger :Le détail du composant Thread n’y figure pas, ainsi que la nature des signauxéchangés entre les modules d’un même composant.

SchedBase

Scheduler

ClockTick

AsyncInterrupt

EndInterrupt

TimerOut

SetTimerDelTimer

EnterSystemMode,ExitSystemMode,Active, Blocked,Free

Awaken

CreateThread

ThreadCreatedThreadDeleted

ClockTickEnterInterruptExitInterrupt

UserSystem

Interrupt, Trap,TrapRet, Exception,ExceptionRet

Hardware

Run

Suspend, Resume, MaskSuspend,UnMaskSuspend, Start, Stop, MaskStop,UnMaskStop, Sleep, Awake, Abort,MaskAbort, UnMaskAbort, DeleteThread,MaskDelete, UnMaskDelete

TimeGuard

Time

InterruptMgr

TimeSlice

SysMode

ExceptionExceptionRet

TrapTrapRet

Interrupt

Thread

TimerMgr

Structure générale du micro-noyau synchrone



2.4. Conclusion

Nous avons réalisé une modélisation complète de la gestion des tâches dunoyau CHORUS. Pour cela nous avons dû effectuer un découpage fonctionnel decette fonction du système. Nous avons prouvé formellement des comportementsnon-triviaux de chacun des éléments qui le composent.

Ce travail a isolé et formalisé le comportement de la gestion des tâches, enfaisant abstraction des problèmes de gestion des données. Cette expérience a misen évidence l’originalité de la programmation synchrone, qui induit un style trèsdifférent d’une programmation classique : pour que l’automate généré modélise lecomportement le plus complet possible, il faut limiter au maximum l’utilisation devariables et valeurs dans les tests conditionnels (if). Cette approche n’est pasnaturelle pour un développeur non averti, et a donné lieu à différentes versions ducode des modules. Lorsque la valeur testée est un booléen, il est très facile de laremplacer, par un bloc parallèle à deux états. Mais il arrive que l’utilisation d’unevaleur entière soit incontournable, comme dans le cas du compteur d’annulationdans le module thSleep . Dans ces situations, une partie du comportement estexportée hors de l’automate, limitant les preuves que l’on peut en faire.

La structure modulaire du système isole chaque sous-comportement dusystème, en facilitant énormément la lecture et les modifications. Ainsi, la gestiondes différentes causes de blocage d’un thread se trouve encapsulée dans lesmodules thStop , thSuspend et thSleep . Dans le code natif de CHORUS, cescomportements sont noyés dans la gestion globale de l’état des threads.

Cette étude ayant produit des résultats positifs, il serait intéressant d’utiliserl’approche synchrone pour la réalisation d’autres éléments du noyau. Toutefois ilconvient de choisir avec soin ces éléments : leur traitement doit être de natureréactive pour que l’approche présente un intérêt. La gestion des communications,par exemple, est propice à une réécriture en ESTEREL. La gestion d’un appel deprocédure distante (RPC) est typiquement un traitement réactif.



3.Chapitre

Mise en oeuvre du modèle

Nous avons présenté dans le chapitre précédent la modélisation en ESTEREL dela gestion des tâches. Nous allons maintenant montrer comment ce modèle peutêtre mis en oeuvre.

La compilation du code ESTEREL de notre gestion synchrone des tâches va nousdonner un ensemble d’objets synchrones. Nous allons définir la façon dont cesobjets vont communiquer, et la machine d’exécution nécessaire à leur bonfonctionnement. Nous présenterons alors une implantation réelle, au niveauutilisateur.

3.1. Composition des modules

Dans le chapitre précédent, nous avons regroupé les modules de notre systèmeen quatre composants. Ces associations étaient motivées par les fonctionnalitésdes modules. Les compositions que nous allons maintenant réaliser vont nousamener à faire des associations de modules sur d’autres critères, afin d’obtenir unensemble d’objets synchrones.

La composition parallèle synchrone est la mise en parallèle de deux modules àl’aide de l’opérateur “||” du langage. Cette composition est elle même un modulesynchrone, les communications et synchronisations qui s’y produisent sont résolusà la compilation [BER83]. Les communications bidirectionnelles entre les modulessont possibles, c’est-à-dire qu’un module peut émettre un signal à un autre module,et ce dernier peut lui répondre dans le même instant. On obtient alors un cycle decommunication entre les modules.

Idéalement, nous souhaiterions combiner l’ensemble des modules de la gestiondes tâches en parallèle synchrone. Cependant deux raisons nous en empêchent :

• La compilation du module résultant produirait un automate de taille tropimportante. Le fichier décrivant l’automate prendrait des centaines deméga-octets, il est dans la pratique impossible à manipuler ou même a créerpar le compilateur.

Mise en oeuvre du modèle 83


• Le parallèle synchrone ne permet pas de gérer une configurationdynamique. Il est impossible de rajouter ou enlever des modules, ou mêmede modifier les connexions entre les modules, puisque tout ceci est fixé unefois pour toutes à la compilation. Or nous avons besoin de dynamicité pourajouter et retirer des modules Thread en cours d’exécution.

Nous devons donc trouver d’autres méthodes de composition de module,respectant les propriétés du synchronisme et les exigences de notre système. Nousallons tout d’abord examiner deux autres méthodes de composition, puis nousprésenterons la solutions retenue.

3.1.1. Le séquencement synchrone

Les modules synchrones sont ici compilés séparément, et les objets générés parla compilation sont exécutés en séquence par un contrôleur commun. Ce derniergère les réactions de l’ensemble des modules, après avoir défini l’ordre dans lequelils doivent être séquencés. Cet ordre est calculé à l’aide des dépendances dessignaux : tout module A prenant pour entrée un signal de sortie d’un module B doitréagir après ce dernier. On dit alors que A dépend de B. La mécanique interne desobjets synchrones étant encapsulée, on est obligé de considérer que tous lessignaux de sortie d’un objet dépendent de tous ses signaux d’entrée. Il estimpossible de définir un ordre de séquencement si le graphe de dépendances desmodules possède un cycle : Deux modules dépendant, directement ou non, l’un del’autre ne peuvent pas être gérés en séquencement synchrone.

Toutefois il est possible de casser la dépendance antre deux objets enintroduisant un objet de type particulier : un retard (Delay ). Cet objet communiqueun signal dans l’instant qui suit celui où il l’a reçu. La communication n’est alorsplus synchrone. Le signal émis par le retard ne dépend pas du signal qu’il reçoit,puisque la réception et l’émission ne se produisent pas dans la même réaction.

Dans le mode de composition par séquencement synchrone, l’ensemble desmodules compilés et le contrôleur forme un seul objet synchrone. Lorsque lecontrôleur est stimulé, il provoque une réaction de l’ensemble des modules dansl’ordre qu’il a déterminé, cette cascade de réactions forme une seule réactionsynchrone de l’objet.

Un objet synchrone peut avoir une configuration dynamique. En effet il estpossible d’enregistrer des requêtes de modification (ajouts/suppression de modules,modifications des connexions), qui seront exécutées au démarrage de la prochaineréaction. Toute modification de la configuration nécessite de recalculer le graphede dépendances des modules, afin d’ordonner la prochaine réaction des modules.Cette opération peut être coûteuse si le nombre d’objets et/ou de signaux estimportant.

Le séquencement synchrone est utilisé pour combiner des modules ayant unerelation unidirectionnelle qui ne peuvent être mis en parallèle synchrone en raisonde la taille excessive de l’automates qu’ils génèreraient. Il est aussi utilisé lorsquela configuration est dynamique.

84 Mise en oeuvre du modèle


3.1.2. Le parallèle asynchrone

Il existe un autre moyen de faire coopérer des modules réactifs, qui estd’utiliser des communications asynchrones [ARC95]. Les modules sont compilésséparément par un outil qui leur donne une interface accessible par d’autresobjets, synchrones ou non. Cette interface permet de faire des communicationsasynchrones de signaux entre ces objets. Il n’existe pas de contrôleur poursynchroniser les réactions des différents objets, il n’existe donc pas de réactionglobale de l’ensemble des objets synchrones.

Cette configuration offre la possibilité de faire communiquer des objets résidantdans des espaces d’adressage différents, et de modifier la configuration sans coûtparticulier. En effet on peut à tout instant supprimer un objet, ou en rajouter un,et cela sans avoir à recalculer les dépendances entre les objets, puisqu’ils sontautonomes. La contrepartie de cette facilité est bien sûr la fragilisation de laconfiguration, puisque c’est à l’application de s’assurer qu’un objet synchrone quiest retiré n’est plus référencé par un autre objet, qui continuerait d’émettre àdestination de l’objet détruit.

Le parallélisme asynchrone autorise les boucles dans les communications entreobjets synchrones, puisque le synchronisme est rompu. Un objet A recevant unsignal en provenance d’un objet B peut répondre à B, mais ce dernier n’aura pasconnaissance du signal de réponse dans la même réaction que le signal qui l’aprovoqué.

L’asynchronisme du parallélisme entre les différents objets synchrones conduità une incertitude quant à l’exécution d’une séquence de réactions mettant en jeuplusieurs objets. Lorsque deux événements à destination de deux objets différentsse produisent, on ne peut pas prévoir l’ordre dans lequel ils seront traités. Or cetordre peut modifier le résultat de ces réactions. Le système est alorsindéterministe.

3.1.3. Application à la gestion des tâches

Voici, en résumé, les caractéristiques importantes des trois modes decomposition que nous venons de présenter :

Déterminisme Cycles Dynamicité Taille réduiteParallèlesynchrone

Oui Oui Non Non

Séquencementsynchrone

Oui Non Oui Oui

Parallèleasynchrone

Non Oui Oui Oui

Le parallèle asynchrone étant indéterministe, le séquencement synchrone est laseule alternative qui s’offre à nous pour traiter les situations où le parallèlesynchrone ne peut être appliqué.



Nous allons passer en revue chacun des modules de la gestion des tâches, etexaminer la façon dont il peut s’intégrer au système.

Les modules de réception des interruptions et de gestion de l’interruptionhorloge sont uniques (non dynamiques) et petits. La composition parallèlesynchrone peut donc leur être appliquée. Le premier objet synchrone résultant decette combinaison sera appelé SyncInterrupt . Le module de redirection desinterruptions logicielles et exceptions, SysMode, sera lui un objet synchroneindépendant, afin de limiter la taille de l’automate de SyncInterrupt . Cettedécision est un choix non définitif, nous aurions tout aussi bien pu réunir ces deuxobjets.

Les modules SchedBase et TimeSlice sont très inter-dépendants. ils ne peuventêtre composés qu’en parallèle synchrone, car ils ont besoin de communicationsbidirectionnelles instantanées. L’objet qui les encapsule a pour nom Scheduler .

Le parallèle synchrone des modules InterruptMgr et Scheduler produit unautomate de taille trop importante (plusieurs méga-octets). Leur communicationsétant unidirectionnelles, ces deux modules peuvent être exécutés en séquencementsynchrone.

La composition en parallèle synchrone des différents modules du composantThread génère elle aussi un automate de taille trop importante. Le graphe descommunications à l’intérieur de ce composant ne possédant pas de cycle, nouscomposerons ces modules en séquencement synchrone. Dans la suite du document,nous désignerons ce groupe d’objets comme étant l’objet Thread , pour ne pas avoirà énumérer l’ensemble de ses constituants.

Le parallèle synchrone entre Scheduler et les modules de contrôle des threadsest impossible en raison de la dynamicité du système (création/destruction dethreads). Les communications entre ces modules sont unidirectionnelles, desthreads vers l’ordonnanceur, ce qui permet de définir un ordre d’exécution de cesmodules. Nous utiliserons donc le séquencement synchrone.

Reste le module TimerMgr , qui possède des communications avec les threads etSyncInterrupt , dans le sens opposé à celles qu’ont ces deux objets entre eux. Cettecommunication génère donc un cycle.



Thread

SysMode SchedulerTimerMgr

SyncInterrupt

Graphe des communications, cyclique

Pour casser ce cycle, nous plaçons un retard entre les objets TimerMgr etSyncInterrupt . SyncInterrupt ne dépend alors plus de TimerMgr , le graphedevient acyclique. Ceci n’est possible que parce que l’information communiquée parce retard concerne la prochaine expiration de timer. Elle n’est pas indispensableavant le prochain tick d’horloge.

3.2. Machine d’exécution

La machine d’exécution a pour rôle d’une part d’assurer la communication dessignaux aux interfaces de la gestion des tâches, et d’autre part de préserver lasémantique du synchronisme en garantissant (i) l’atomicité des réactions, et (ii)l’invariance des événements en entrée pendant un réaction.

Notre machine d’exécution se situe à un niveau bas dans le système, deuxcontraintes vont guider sa réalisation :

• Puisqu’elle doit permettre l’exécution de la gestion des tâches, elle ne peutpas profiter de ses fonctionnalités; elle n’aura donc pas la possibilité de sebaser sur des threads, et ne disposera d’aucun des mécanismes qui leursont associés (sémaphores, mutex ...)

• Il ne s’agit pas de réécrire un noyau pour exécuter un noyau. Notre objectifétant l’encapsulation du comportement du système dans du code synchrone,nous ne devons pas déporter une partie de ce comportement dans lamachine d’exécution. Elle doit donc être très simple.

Notre machine d’exécution est minimum dans ses fonctionnalités, mais elle doitpouvoir gérer des configuration complexes. En effet nous sommes en présence d’unnombre important d’objets synchrones ayant des connexions multiples(multiplexage/ démultiplexage), et devant supporter la dynamicité : on peut à tout



moment créer un thread, et donc instancier un nouveau module de contrôleThread , avec les connexions que cela implique.

Nous appellerons cette machine d’exécution StmEm (Synchronous ThreadManager’s Execution Machine). Elle encapsule l’ensemble des objets synchrones dela gestion des threads en un unique objet réactif : le micro-noyau synchrone.

Les premières analyses des machines d’exécution ont permis de faire undécoupage logique des opérations à réaliser [BER93]. La séquence d’opérations quipermet la réaction d’un objet synchrone peut être décomposée en cinq modules.

Collecteurd’événement

d’entrée

Constructeur del’événement de

réaction

Exécution dela réaction

Collecteur del’événement

sortant

Emetteurd’événements

de sortie

Architecture générale de la machine d’exécution

3.2.1. Collecteur d’événements d’entrée externes

Ce module a en charge la détection des modifications de l’environnement, lesévénements externes, qu’il traduit en signaux ESTEREL, éventuellement en leurassociant une valeur. Il est donc responsable de la liaison entre un objet synchroneet le monde asynchrone. Il est composé d’un ensemble d’objets d’interface, chacunayant la charge de la réception d’un signal. Le collecteur informe le module deconstruction de l’événement de réaction lorsqu’un événement se produit, afin qu’ilsache qu’au moins un signal est présent et donc qu’une réaction peut avoir lieu.Tant que le collecteur d’événements externes n’a pas détecté d’événement, il n’y aaucune raison de lancer une réaction.

3.2.2. Constructeur de l’événement de réaction

Un événement de réaction est un ensemble de signaux ESTEREL qui est fournien entrée d’un automate lors d’une réaction. Le constructeur d’événements utilisela connaissance qu’il a des contraintes associées aux signaux de l’automate pourdécider s’il faut lancer une réaction, et avec quel événement en entrée.

On pourrait imaginer différentes politiques, plus ou moins complexes, dedéclenchement d’une réaction. Par exemple une exécution périodique, ou bien suroccurrence de combinaisons de signaux, ou encore un mélange de ces conditions...Ce type de politique introduit un comportement complexe en dehors du mondesynchrone, dans un code indéterministe et non prouvé. Nous nous limiterons doncà une politique très simple.

Nous ne définissons que deux règles :



1. Seul l’affectation d’un signal peut provoquer une réaction de StmEm, ce quigarantit qu’il ne réagira que si au moins un signal est présent à soninterface d’entrée.

2. Il existe deux types de signaux : ceux qui font réagir StmEm immédiatement,que nous qualifierons de stimulant, et ceux qui ne font que positionner unevaleur de signal, qui sera prise en compte à la prochaine réaction, que l’onpeut qualifier d’informatifs.

La distinction stimulant/informatif se justifie par le fait que tous les signauxn’ont pas le même effet sur les objets synchrones, certains modifiant uniquementl’état interne de l’objet, d’autres pouvant provoquer l’émission de signaux externes.Dans le premier cas, il n’y a pas d’urgence à traiter le signal, lors de la prochaineréaction, déclenchée par l’occurrence d’un signal stimulant, la modification del’état interne sera effective de la même façon que si elle avait fait l’objet d’uneréaction immédiate. C’est ce qui se produit, par exemple, pour les signaux demasquage des opérations d’ordonnancement : lorsque l’on demande le masquage del’arrêt d’un thread, cela n’aura un impact sur le système que lors de la prochainedemande d’arrêt. Ainsi les signaux de masquages sont déclarés informatifs, ils neprovoquent pas de réaction du noyau. C’est l’occurrence du prochain signalstimulant qui entraînera leur traitement. Seul le concepteur d’une applicationsynchrone sait si un signal est stimulant ou informatif. Il peut utiliser des outilsformels pour s’assurer de la justesse de se décision. L’action abstraite suivante,vérifiée impossible, nous assure que le module thSleep n’émet aucun signallorsqu’il n’a en entrée que le signal MaskAbort :

true* :/MaskAbort? and not /UnMaskAbort? and not /DeleteThread?and not /Abort? and not /TimerOut? and not /Awake? and not /Sleep?and (/BeReadySleep! or /BeUnReadySleep! or /DelTimer! or /SetTimer! or /Awaken!)

Définir des signaux informatifs permet de diminuer le nombre de réactionsd’une application synchrone, et donc d’en améliorer les performances, sans enmodifier le comportement.

3.2.3. Exécution d’une transition

L’événement construit par le module précédent est placé en entrée del’automate, qui exécute alors sa réaction, pendant laquelle il ne doit avoir qu’unevision fixe de son environnement : son événement d’entrée ne peut pas êtremodifié. Pour respecter la propriété du synchronisme, la machine d’exécution doitpréserver l’atomicité de la réaction de StmEm quand un signal se produit pendantson exécution.

Les seuls événements pouvant survenir pendant l’exécution d’une réaction sontles interruptions matérielles, qui peuvent se produire à tout moment. Les autresévénements sont générés soit à la suite d’une réaction d’un objet synchrone, soitpar du code contrôlé par l’ordonnanceur (le thread courant ou un gestionnaired’interruption).



Si l’on ne considère pas les interruptions matérielles, qui sont donc les seulsévénements asynchrones de notre système, on a le comportement suivant :

1. Un événement se produit, son occurrence génère l’exécution de StmEm, quitraite cet événement.

2. Ce traitement a consisté à modifier l’état du système, et éventuellement àpréparer un nouveau contexte d’exécution, lorsque l’événement le requiert.Dans ce cas, le passage à ce nouveau contexte se produit à la fin de laréaction.

3. On exécute alors le code du contexte préparé par la réaction, jusqu’à cequ’un nouvel événement se produise (retour en 1).

Si une interruption se produit pendant du code autre que celui de StmEm,l’interruption provoque une réaction de StmEm, ce qui correspond au comportementdécrit ci-dessus. Par contre, si l’interruption se produit pendant l’exécution deStmEm, il ne faut pas interrompre cette exécution. On pourrait être tenté deprendre en compte ce nouveau signal le plus vite possible, et donc d’interrompre laréaction en cours. On se trouverait alors devant deux alternatives : soit annulertotalement la réaction et la reprendre depuis le début avec en plus le nouveausignal, soit arrêter la réaction de StmEm à la fin de l’objet synchrone en cours deréaction, et redémarrer une réaction de StmEm en ayant supprimé les signaux déjàconsommés, en conservant ceux qui restent, aussi bien en entrée que ceux produitsen internes, et en y ajoutant le nouvel arrivé. Ces comportements sont bien tropcomplexes pour notre machine d’exécution qui doit être minimum. Ils nuiraient audéterminisme et aux vérifications qui nous pourrions faire de notre système, enexportant hors de la description synchrone une partie du comportement.

L’occurrence de l’interruption sera prise en compte à la fin de la réaction encours. L’impossibilité d’interrompre la machine d’exécution assure l’atomicité desréactions. Cette protection des réactions peut être assurée par un mécanismesimilaire au verrouillage du noyau CHORUS. Les réactions déclenchées parl’exécution normale des threads verrouillent StmEm, indiquant qu’il est en cours deréaction. Lorsqu’une interruption survient, elle teste l’état du verrou; s’il est libre,l’interruption émet le signal Interrupt qui provoque une réaction; sinonl’interruption insère son numéro dans une liste d’interruptions en attente. Dans cecas, c’est le prochain déverrouillage de StmEm qui détectera les interruptions nontraitées, provoquant une nouvelle réaction du micro-noyau.

Notre système étant composé de plusieurs objets synchrones, la machined’exécution devra décider à chaque stimulation quels objets faire réagir, et dansquel ordre.

Tous les objets qui ont un signal en entrée doivent réagir. Une réaction d’unobjet qui n’a pas de signal présent en entrée ne sert à rien.

L’ordre dans lequel sont exécutées les réactions des objets synchrones estdéterminé par leurs communications. Les objets Thread émettent vers l’objetScheduler , qui lui n’émet jamais vers les Thread . L’ordonnanceur crée les modules



de contrôle des threads, mais il ne faut pas considérer cela comme unecommunication bidirectionnelle, car un module Thread n’est pas présent dans laréaction de StmEm qui génère son instanciation. La création effective et les mises enoeuvre des structures de communications ne sont réalisées qu’à la terminaison decette réaction, ainsi on ne se trouve jamais dans une situation ou Scheduler créeun Thread qui lui émet un signal dans la même réaction.

Le graphe des communications entre les objets synchrones permet de définir unordre d’exécution (il en existe plusieurs valides) entre ces objets, qui assure quetout objet s’exécute avant les objets auxquels il envoie un signal. Nous utiliseronspar exemple la séquence suivante :

ThreadSysMode Scheduler TimerMgrSyncInterrupt Delay

La première réaction de l’objet synchrone est particulière, elle a pour rôled’initialiser l’automate. Elle s’exécute sans considérer les signaux en entrée. Cettetransition effectue l’affectation des valeurs initiales des variables, et tout le code setrouvant avant la première attente d’un signal dans le programme ESTEREL. Cecode peut émettre des signaux, faire du calcul sur ses variables locales ou appelerdes procédures externes. Le lancement de cette transition se fait à la création del’objet synchrone, sans exécuter les collecteur et constructeur d’événementsd’entrée, puisque l’automate n’attend aucun signal.

3.2.4. Collecteur de l’événement sortant

Le collecteur d’événements de sortie a un rôle de stockage, il récupère en coursde transition les signaux émis par l’automate. Leur ensemble, à la fin de laréaction, constitue l’événement de réaction sortant. Les signaux sont placés dansun ensemble d’objets d’interface, symétriques de ceux en entrée. Lorsque laréaction est terminée, il signale à l’émetteur d’événements de sortie que l’émissioneffective peut commencer.

3.2.5. Emetteur d’événements de sortie

L’émetteur d’événements de sortie récupère les données du collecteurd’événement sortant et les traduit en événements externes, qui, comme en entrée,peuvent prendre plusieurs formes : communication par messages, par mémoirepartagée...

L’émission des événements externes, qui est logiquement simultanée d’après lasémantique des langages synchrones, est forcément séquentielle surmonoprocesseur. L’ordre d’émission n’a pas d’importance.

L’émission des signaux Run et AsyncInterrupt n’est pas du même type que lesautres, car ils ne sont pas attendus, ni par du code synchrone, ni par du codeasynchrone. Leur occurrence correspond à une modification du contexte



d’exécution. Il leur est donc associé un objet d’interface particulier, qui exécute ducode asychrone à chaque occurence du signal auquel ils sont connectés.

3.2.6. Analyse de la durée des réactions

Nous décomposons cette analyse en deux parties : d’un part l’analyse de laréaction d’un objet synchrone, puis celle de la séquence des réactions de l’ensembledes objets de la gestion des tâches.

3.2.6.1. Réaction d’un objet synchrone

Un des intérêts de l’approche synchrone est la génération d’un code dont ladurée d’exécution peut être plus facilement bornée. Toutefois elle n’est pas uniquepour toutes les réactions, car le code exécuté dépend de la combinaison de signauxprésents en entrée, de leurs éventuelles valeurs et de l’état des variables internes.Pour les programmes en ESTEREL pur (sans signaux valués ni variables), il estassez simple de calculer le temps de calcul maximum et minimum des réactions, ilsuffit de considérer le code exécuté pour chaque combinaison de signaux autorisée.Le nombre de ces combinaisons est :

NbComb NbExc 1 NbExcnnbSigI

n 1

nbSigInbSigIC 2= − = − −

=∑

où nbSigI est le nombre de signaux en entrée, et NbExc est le nombre decombinaisons interdites par les relations d’exclusion ou d’implication déclaréesdans le module ESTEREL. Une relation d’exclusion entre deux signaux (I1#I2 )interdit 2nbSigI-2 combinaisons, autant qu’une relation d’implication (I1=>I2 ).

Dans la pratique, même si un grand nombre de combinaisons sont acceptées,seules quelques unes sont pertinentes pour l’automate, qui dans chaque étatn’attend qu’un nombre limité de signaux. Le fichier de description de l’automateproduit par la compilation du code ESTEREL contient une liste de signaux attenduspour chaque état. A partir de cette information, il est possible de calculerprécisément le nombre de combinaisons attendues par un automate en fonction deson état.

Pour un programme écrit en ESTEREL pur, on peut en déduire une liste finie etexacte des réactions possibles de l’automate. Deux méthodes permettent alors decalculer la durée des réactions : le code peut être analysé en faisant la somme desdurées de chaque instruction d’une réaction; ou bien on peut par simulationmesurer les temps d’exécution de chaque réaction, en présentant à l’automate,dans chacun de ses états, l’ensemble des combinaisons de signaux qu’il traite.Dans ce dernier cas il faut être sûr de ne pas avoir de perturbation des mesurespar une interruption ou une préemption.

Pour les programmes ESTEREL non purs, la situation est plus complexe,plusieurs éléments viennent perturber les mesures. Tout d’abord la valeur desvariables internes peut modifier le code exécuté. Par exemple la durée exacte de lacommande “if (myVar > 0) then <bloc1> else <bloc2> endif; ” ne peut être



déterminée statiquement (même si elle peut être bornée), la valeur de myVar étantinconnue avant l’exécution. Les mesures par simulation sont alors complexes, il estdifficile d’être sûr d’avoir simulé toutes les situations. Par contre une analyse ducode permet toujours de mesurer tous les chemins possibles du flot d’exécution, etd’en déduire la durée minimum et maximum de chaque réaction. Un deuxièmeproblème est lié à la possibilité d’appeler du code “externe”, c’est-à-dire non-ESTEREL, depuis un module. Ceci prend différentes formes dans notre système :appels de procédures et de fonctions, et utilisation de types qui ne sont pas natifsESTEREL. Ces types correspondent alors à des classes C++, dont il faut avoir définiles opérateurs utilisés dans le code ESTEREL : l’affectation (:=), les comparaisons(=, <, >...), et éventuellement les opérations mathématiques (+,-,*,/). Le code alorsexécuté n’est plus déterministe; il peut contenir des boucles dont le nombred’itérations n’est pas calculable a priori (des boucles while( condition ) parexemple), ou bien des appels à des librairies du langage dont on ne connaît pasprécisément la durée... Seule la mesure des temps d’exécution de chacune de cesfonctions externes permet alors d’avoir une idée de leur durée, mais sans garantied’avoir capturé les valeurs minimum et maximum. La durée maximum de réactionde l’objet i s’exprime alors par une formule du type :

TRmax TAmax fmaxi i i= + ∑

TAmaxi (durée maximum du code de l’automate) est connue, Σfmaxi (sommedes durées maximum des fonctions externes) est estimée.

Dans le cadre de cette thèse, nous n’avons pas fait d’analyse fine des durées desréactions. Seule une analyse des performances globales du système, présentée plusloin dans ce chapitre, a été menée.

3.2.6.2. Réaction de l’ensemble des objets synchrones

Le temps maximum de réaction T de l’ensemble des objets synchrones, exécutésen séquence, est la somme de leur durée maximum de réaction.

La borne inférieure M de cette exécution correspond à la réaction la plus petitepossible. S’il y a réaction, c’est qu’il y a au moins un signal donc au moins un objetqui réagit, et il est des signaux qui peuvent ne faire réagir qu’un objet : parexemple un thread demandant la suspension d’un thread déjà suspendu ne faitréagir que le module Thread concerné, puisque le thread ne change pas d’état. Laplus petite réaction de StmEm n’est donc composée que d’une réaction d’un de sesobjets synchrones.

La borne du temps de réaction du système, c’est-à-dire le délai maximum entrel’occurrence d’un signal et la réalisation de son effet (par exemple l’émission d’unblocage de thread et l’élection/exécution d’un autre thread) est égale au tempsnécessaire pour terminer une éventuelle réaction en cours, plus la durée dutraitement du signal :

R = 2.T



3.2.7. Communications

La communication entre les différents modules que nous avons présentés étanttoujours locale (tous ces modules sont sur un même site), et ces modules ce situantdans un même espace d’adressage (l’espace système), il est possible de réaliser lescommunications par mémoire partagée.

Les événements Active et Blocked des objets Thread doivent être multiplexéssur les événements Active(ThreadRefList) et Blocked(ThreadRefList) enentrée de Scheduler . Ceci est assuré par un objet de communication particulier,qui transmet, en plus de l’occurrence du signal, la référence du thread qui l’a émis,et l’ajoute à la liste passée en valeur du signal en entrée de Scheduler .

Inversement, les événements Delete(ThreadRef) en provenance de Scheduler

doivent être démultiplexés sur les événements Delete des modules Thread

correspondants. Cette fonction peut être réalisée de deux façons : soit l’émetteurmémorise la liste de ses destinations, et effectue une sélection parmi cette liste enfonction de sa valeur courante, soit l’émetteur diffuse sa valeur à toutes sesdestinations, ce sont alors les émetteurs qui filtrent avec la valeur qui leur estassocié.

3.3. Comment ça se passe ?

Après avoir présenté les différents éléments de notre modèle, nous proposonsici un exemple qui va permettre de reconstituer une image globale du système.

3.3.1. Un exemple

Supposons qu’il y ait un thread T1, de priorité moyenne, en cours d’exécution. Ilgénère un événement de la gestion des tâches, par exemple il invoque l’opérationthreadSuspend() sur un thread T3 de plus faible priorité qui était prêt et enattente du processeur. Pendant le traitement de cet événement survient uneinterruption, qui appelle threadResume() sur un thread T2, de priorité supérieureà T1. Examinons ce qui se passe dans le cas du traitement actuel de CHORUS etdans le cas de notre gestion synchrone.

Dans CHORUS, l’appel système threadSuspend() verrouille le noyau par laprimitive KnLock , ce qui a pour effet de geler l’ordonnancement jusqu’à la fin dutraitement de threadSuspend . L’interruption matérielle se produit, elle est traitéeimmédiatement, et invoque l’opération threadResume , ce qui rend le thread T2

prêt, il est placé en tête de file d’attente des threads car il est le plus prioritaire. Ala fin du traitement d’interruption, on teste si la valeur du verrou, et comme il estbloqué par T1 la procédure KnUnLock n’est pas appelée, il n’y a donc pas depréemption, T2 ne prend pas le processeur. On revient alors au contexteinterrompu, qui était l’exécution de threadResume qui se termine et fait KnUnLock ,ce qui provoque l’élection de T2 qui prend le processeur.

Dans le cas de notre modèle, voici ce qui se passe :



1- L’appel à threadSuspend() que fait T1 provoque l’émission du signalSuspend(T3) en entrée de la machine d’exécution. Cette émission provoque uneréaction de StmEm. Les objets SyncInterrupt et SysMode n’ayant aucun signal enentrée, ils ne réagissent pas. StmEm parcours alors la liste des objets Thread , etfaire réagir celui qui contrôle T3, que nous appellerons rThread3 . Cette exécutiongénère l’événement Blocked(T3) à destination de l’objet Scheduler , indiquant queT3 n’est plus prêt à s’exécuter. Pendant cette réaction, l’interruption se produit,tente de verrouiller StmEm, et constatant qu’il est déjà en cours d’exécution noteuniquement le numéro d’interruption dans la liste des interruptions en attente.

2- A la fin de la réaction de rThread3 , StmEm fait réagir Scheduler , puisqu’il ale signal Blocked en entrée. Les objets TimerMgr et Delay ne sont pas exécutés,n’ayant pas de signal à traiter.

3- C’est alors la fin de la réaction de StmEm, qui se déverrouille, opération aucours de laquelle est détectée la présence du signal d’interruption en attente. Unenouvelle réaction est alors lancée.

4- Cette réaction provoque l’exécution de SyncInterrupt , qui cette fois possèdele signal Interrupt en entrée, avec en paramètre le numéro de l’interruption quis’est produite. Cet objet émet alors les signaux EnterInterrupt , versl’ordonnanceur, et AsyncInterrupt , pour mettre à jour le contexte d’exécution.

5- Les objets SysMode et Thread n’ayant pas de signaux à traiter, StmEm passedirectement à l’exécution de la réaction de Scheduler , qui prend en compteEnterInterrupt en mémorisant qu’il ne faut pas pour l’instant affecter leprocesseur à un thread.

6- Les objets TimerMgr et Delay ne sont pas stimulés, la réaction de StmEm setermine, le signal externe AsyncInterrupt est émis, provoquant l’affectation ducontexte d’exécution avec celui du gestionnaire de l’interruption qui s’est produite.

7- Ce gestionnaire veut réveiller le thread T2 en émettant Resume(T2) , StmEm

réagit en exécutant rThread2 , qui note que le thread T2 devient actif et émetActive(T2) , ce qui stimule Scheduler , qui, sachant que l’on est toujours en moded’interruption, ne lance pas ce thread.

8- Puis le gestionnaire signale sa terminaison en émettant EndInterrupt ,faisant réagir de nouveau StmEm avec cette fois les objets SyncInterrupt , quisignale la sortie du mode d’interruption en émettant ExitInterrupt , et Scheduler ,qui traite ce signal en émettant Run(T2) , indiquant que l’on doit mettre le systèmedans le contexte d’exécution de ce thread. C’est le déverrouillage de StmEm quieffectue le changement de contexte, après avoir vérifié qu’il n’y avait pasd’interruption en attente.

3.3.2. Commentaires

Le traitement décrit ci-dessus a nécessité 4 réactions de StmEm, qui ont exécutéen tout 8 réactions d’objets synchrones. Il est possible de réduire le nombre deréactions en observant les propriétés des gestionnaires d’interruptions :



• Ils ne sont pas exécutés par des threads, les opérations de manipulation dethreads qu’ils demandent au système ne peuvent donc pas les concerner. Enparticulier un gestionnaire d’interruption ne peut demander la mise enattente de son thread, puisqu’il n’en a pas.

• Toutes les opérations sur les threads qu’ils demandent sont sans effet tantque l’exécution du gestionnaire d’interruption n’est pas terminée.

Ceci veut dire que l’on n’a pas besoin de faire réagir le micro-noyau auxopérations sur les threads que demande un gestionnaire d’interruption tant que cedernier n’a pas émis son signal de terminaison EndInterrupt . Ceci n’est vrai queparce que la seule opération de gestion de thread qui attende une réponse estjustement l’opération d’attente (threadDelay ), que les gestionnaires ne peuventpas demander. Il en existe en fait une autre : la création de thread, qui retournel’identificateur du thread créé. Le signal CreateThread devra donc faire réagir lemicro-noyau.

L’optimisation consiste, lorsqu’un gestionnaire d’interruption est en coursd’exécution, à ne définir stimulant que les signaux Interrupt (pour prendre encompte de nouvelles interruptions), EndInterrupt (pour sortir du moded’interruption) et CreateThread .

Dans l’exemple que nous venons de présenter, cette optimisation permetd’économiser une réaction de StmEm, et une réaction de Scheduler , qui traiterasimultanément Active(T2) et ExitInterrupt .

3.4. Implantation du système

Nous avons présenté le code synchrone ESTEREL réalisant le contrôled’exécution des tâches d’un système d’exploitation, puis nous avons présenté lesfonctionnalités attendues de la machine d’exécution permettant d’assurer la miseen oeuvre de ce code. Nous allons maintenant présenter une implantation réelle decet environnement.

3.4.1. Objectif et choix d’implantation

Cette implantation a pour objectif de valider le modèle que nous avonsprésenté, elle nous permettra de mettre en évidence sa faisabilité et vérifier qu’ilpossède les fonctionnalités que nous souhaitons.

Nous ne voulons pas réécrire totalement un noyau de système d’exploitation,car il faudrait alors développer de nombreux éléments du système qui ne nousintéressent pas, et qui prendraient un temps considérable à écrire : gestion desinterfaces utilisateur (écran, clavier, langage de commande), des périphériques, dela mémoire...

Nous avons alors deux possibilités :

• Modifier un noyau existant, ce qui nous évite les développementsinintéressants, mais nous plonge dans une structure de noyau à laquelle



nous serons contraint de nous adapter, éventuellement au détriment de ceque nous aurions souhaité;

• Implanter notre gestion des tâches au niveau utilisateur, au-dessus d’unsystème d’exploitation complet. Nous avons alors toute liberté pourorganiser notre système, et nous gardons le bénéfice de l’existant en faisantappel, pour ce que nous ne développerons pas, au système sous-jacent.

Nous choisissons cette deuxième solution, en raison de son indépendance vis-à-vis d’un noyau existant. On obtient alors un “processeur virtuel” possédant sonpropre ordonnancement, exécutant plusieurs threads utilisateur, le toutmultiplexé au-dessus d’un thread de base ordonnancé par le noyau.

Si notre gestion des tâches ne prenait en compte que des événements généréspar les tâches qu’elle gère, elle pourrait être totalement indépendante du noyau.Puisque nous souhaitons récupérer des interruptions matérielles, il est nécessaired’instaurer un dialogue entre l’espace d’adressage système et celui utilisateur. Ilfaut que l’occurrence d’une interruption puisse interrompre le processeur virtuel,et modifier son contexte pour qu’il récupère l’information concernant l’occurrencede l’interruption. Nous obtiendrons alors un ordonnancement préemptif.

Nous effectuerons notre développement au-dessus du micro-noyau CHORUS, ennous inspirant, pour ce qui est de la communication entre le noyau etl’ordonnancement utilisateur, d’une mise en oeuvre d’un ordonnancement de cetype développé à l’université de Lancaster [ROB95]. Nous appellerons lesprocesseurs virtuels ainsi réalisés “Processeurs Virtuels Synchrones”, nousutiliserons plus généralement l’abréviation SVP (Synchronous Virtual Processor).

Ordon. utilisateur

Ordonnancement noyau

micro-noyau synchrone

n threadsutilisateur

un seulthread noyau

partaged’infos

ProcesseurVirtuel

Synchrone

NOYAU

tâche"classique"

autre type deprocesseur

virtuel

Architecture du système avec Processeurs Virtuels Synchrones



Comme le fait apparaître la figure ci-dessus, cette méthode de développementpermet non seulement d’avoir sur un même système plusieurs processeurs virtuelsayant les politiques d’ordonnancement différentes, mais elle permet aussid’exécuter des tâches classiques ne se basant que sur des threads noyau.

Un SVP est implanté dans un acteur CHORUS. Il dialogue avec le noyau par IPCpour s’initialiser, puis par partage de données. Le noyau CHORUS est modifié afind’intégrer cette coopération.

3.4.2. Interfaces de la gestion des tâches

La gestion des tâches possèdent deux interfaces : l’une utilisateur permet lescréations, modification, et destructions des threads; l’autre, avec le noyau, assurela communication des interruptions matérielles vers les SVP.

3.4.2.1. Interface utilisateur

Tous les appels aux fonctions de notre gestion des threads sont préfixés par“svp_ ” afin de ne pas les confondre avec ceux du système.

L’interface de programmation de notre environnement reprend la totalité desappels système CHORUS permettant de manipuler l’état des threads :

// Creation d’un thread

ThreadRef svp_threadCreate( int initstat, const SchedParams &param,

VmAddr entry, unsigned stack_sz=2048 );

// Destruction d’un thread

int svp_threadDelete( ThreadRef th );

// Update/get scheduling parameters

int svp_threadScheduler( ThreadRef, SchedParams *oldp,

SchedParams *newp );

// Delay-Abort

int svp_threadDelay( unsigned delay );

int svp_threadAbort( ThreadRef th );

// Suspend - Resume

int svp_threadResume( ThreadRef th );

int svp_threadSuspend( ThreadRef th );

// Start - Stop

int svp_threadStop( ThreadRef th );

int svp_threadStart( ThreadRef th );

// Identificateur du thread courant

ThreadRef svp_threadSelf();

Les quelques modifications par rapport au noyau CHORUS sont :

• Le type ThreadRef a été créé pour définir les identificateurs des threads.C’est un entier. Cette définition accroît la portabilité du code, et facilite lareconnaissance de la nature des paramètres des opérations.



• La fonction de création de thread prend comme paramètre une valeur detype SchedParams , qui permet de passer des caractéristiques (période,échéance...) de thread plus complexes que la seule priorité utilisée dansCHORUS. Cependant, seule la priorité est utilisée pour le moment, puisquenous n’avons pas développé d’autre politique d’ordonnancement que celle àpriorité de CHORUS.

• Il faut passer une taille de pile, et non plus une adresse, comme paramètrede création de thread. Ceci évite au développeur les déclarations etréservations fastidieuses de celles-ci. De plus, si l’utilisateur ne préciseaucune taille, il en existe une par défaut.

Les fonctionnalités des sémaphores et mutex, les deux outils de base desynchronisation présents dans CHORUS, sont reproduits, avec une interfacesimilaire :

int svp_semInit(svpSem*, unsigned init_value);

int svp_semP(svpSem*, int delay);

int svp_semPnAbort(svpSem*, int delay); // non abortable

int svp_semV(svpSem*);

int svp_mutexInit(svpMutex*);

int svp_mutexGet(svpMutex*);

int svp_mutexRel(svpMutex*);

int svp_mutexTry(svpMutex*);

D’autres fonctions de gestion du SVP sont présentes :

// terminaison du SVP courant

void svp_Delete();

// lecture de la date noyau (partagée par tous les SVP)

int svp_chorusTimeL( KnTimeVal* tv );

Gestion des interruptions matérielles

// connection d’un gestionnaire d’interruption

void svp_ItConnect( int it, VmAddr handler );

// deconnection d’un gestionnaire d’interruption

void svp_ItDisconnect( int it );

// fin de traitement d’interruption, ne revient pas

void RetIT();

Gestion des interruptions logicielles :

// connexion d’un gestionnaire d’interruption logicielle

void svp_TrapConnect( int id, svp_handler f );

// deconnexion d’un gestionnaire d’interruption logicielle

void svp_TrapDisconnect( int id );

// génération d’une interruption logicielle



int svp_Trap( int id, void* param=NULL );

Gestion des exceptions :

// connexion d’un gestionnaire d’exception

void svp_ExceptionConnect( int id, svp_handler f );

// deconnexion d’un gestionnaire d’exception

void svp_ExceptionDisconnect( int id );

// génération d’une exception

int svp_Exception( int id, void* param=NULL );

3.4.2.2. Interface avec le noyau

Pour communiquer avec le noyau, les SVP possèdent une interface qui présentedeux aspects : Un dialogue par messages IPC et une zone de mémoire partagée.

• Dialogue par messages IPC

Lorsqu’un nouveau SVP est créé, il se déclare au noyau pas le biais d’unipcCall, ce qui entraîne l’allocation et la mise a jour de structures de donnéesrelatives à leur gestion. En effet c’est le noyau qui alloue la zone de mémoirepartagée, et il maintient une liste permettant d’y accéder. Après avoir effectuécette opération, le noyau retourne au SVP l’adresse de la zone qui lui est allouée.

Lorsqu’un SVP se termine, il avertit le noyau afin que celui ci libère la zone demémoire qui lui était associé et mette à jour sa liste de SVP.

Pour effectuer ces opérations, le noyau possède un serveur, implémenté sous leforme d’un thread bouclant en attente sur une porte IPC, et traitant les requêtesdes SVP. Ce serveur est lancé à l’initialisation du noyau CHORUS.

• Une zone de mémoire partagée

Elle est accédée en lecture et en écriture par le noyau et le SVP. Elle contientun pointeur sur la date noyau, qui est ainsi partagée par tous les SVP, mais ellecontient surtout des informations relatives au SVP : l’identificateur de l’acteur, duthread noyau sur lequel sont multiplexés les threads utilisateur, le verroupermettant de protéger l’accès concurrent à StmEm, l’adresse de la fonctiond’interruption du SVP, la liste des interruptions en attente d’être traitée, la listedes interruptions que le SVP s’attend à recevoir (pour lesquels il dispose d’ungestionnaire), et un contexte permettant de mémoriser l’état du SVP au momentd’une interruption.

3.4.3. Exécution des réactions du noyau synchrone

Chaque fonction de manipulation de threads émet au moins un signal. S’il eststimulant, ce qui est le plus souvent le cas, il va provoquer une réaction du micro-noyau synchrone, sinon il sera pris en compte lors la prochaine réaction, initiée parun autre signal.



Avant l’émission de ce signal, le micro-noyau est verrouillé. Cette opération estréalisée en incrémentant le verrou contenu dans la zone de mémoire partagée. Ceverrouillage empêche le noyau de pouvoir lancer un traitement d’interruption,assurant ainsi qu’une réaction ne va pas en interrompre une autre. A la fin de laréaction de StmEm, le verrou est décrémenté. Cette décrémentation est toujoursprécédée d’un parcours de la liste des interruptions en attente, qui auraient pu seproduire pendant le verrouillage. Si c’est liste n’est pas vide, la procédure dedéverrouillage émet les signaux Interrupt correspondant et lance une réaction deStmEm.

Le changement de contexte ne fait pas partie de la réaction de StmEm, car il fautque la réaction soit terminée pour pouvoir exécuter le nouveau contexte (cf.atomicité des réactions). Elle est donc effectuée par le déverrouillage du noyau,après avoir testé la présence d’éventuelles interruptions en attente. Si unchangement de contexte doit être effectué, suite à l’émission du signal Run ouAsyncInterrupt par StmEm, ce déverrouillage est effectué juste avant (dernièreinstruction assembleur) l’affectation de la nouvelle valeur du registre PC.

Le SVP crée à son initialisation un thread utilisateur qui sera exécuté dès qu’iln’y aura aucun autre thread à exécuter. Dans ce cas ce thread suspendra le SVP eninvoquant la primitive système “threadSuspend() ”. Le SVP ne pourra donc pluss’exécuter tant que le noyau, sur réception d’une interruption, ne le réveillera pasen invoquant “threadResume() ”.

3.4.4. Transmission des interruptions au SVP

L’occurrence d’interruptions matérielles est redirigée par le noyau sur les SVPqui en font la demande. Pour cela chaque SVP dispose, dans sa zone de mémoirepartagée avec le noyau, d’une méthode emitInterrupt(it) que peut utiliser lenoyau pour provoquer dans le SVP l’émission de signal Interrupt(it) et laréaction du micro-noyau. Une procédure nommée broadcastInterrupt(it) secharge d’appeler cette opération sur chaque SVP. Pour faire suivre uneinterruption matérielle dans un SVP, il suffit donc de déclarer dans le noyau ungestionnaire de cette interruption qui appelle broadcastInterrupt(it) .

Voici le détail de ce que fait la procédure emitInterrupt(it) : Si le SVP n’apas demandé cette interruption, on quitte immédiatement la procédure. Sinon onajoute le numéro d’interruption dans la liste des interruptions en attente d’êtretraitées. Puis on essaye de verrouiller le SVP, s’il l’est déjà on ne fait rien d’autre.Sinon si le thread noyau du SVP est suspendu, ce qui indique qu’il n’y a plus dethread utilisateur prêt à s’exécuter, on le réveille. Puis on lit le contexte du threaddu SVP, on le sauvegarde, et on affecte son registre PC avec l’adresse d’uneprocédure RunInterrupts() dans le SVP.

Si le micro-noyau a pu être verrouillé, lorsque l’ordonnanceur noyau relancerale thread du SVP, il exécutera RunInterrupts() , mais dans le contexte qui a étéinterrompu. Cette fonction doit donc sauvegarder les registres généraux quiétaient peut-être en cours de manipulation. Mais juste avant cela elle empile uneadresse de retour, à laquelle le PC se branchera lors de la fin de la procédure. Ces



deux opérations étant faites, on exécute un déverrouillage de StmEm, qui aura poureffet non seulement de décrémenter le verrou qui avait été incrémenté par lenoyau, mais aussi d’émettre les signaux Interrupt correspondant auxinterruptions mémorisées dans le liste d’attente, et de faire réagir StmEm. Tout sepasse donc comme si le thread qui s’exécutait au moment de l’interruption avait delui même effectué un verrouillage-déverrouillage de StmEm.

Une interruption seproduit, elle

verrouille et lanceune réaction

La réaction se termine,il n’y a plus d’interruptionsen attente

Redirection d’interruption : micro-noyau non verrouillé

Par contre si le verrouillage n’a pas pu être fait, c’est qu’une réaction du micro-noyau est déjà en cours, il y aura donc un déverrouillage à sa terminaison, quiconstatera la présence d’interruptions en attente et les traitera.

Le thread en courslance un réaction

Une interruption seproduit

La réaction se termine,elle détecte l’interruptionen attente et relanceimmédiatement uneréaction

Le micro-noyauest verrouillé

Redirection d’interruption : micro-noyau déjà verrouillé

3.4.5. Performances

3.4.5.1. Taille du code

Nous donnons ici la taille (en lignes) du code synchrone (c’est-à-dire le sourceESTEREL) et externe pour donner une idée de la proportion entre les deux. Le codeexterne est celui réalisant d’un part les fonctions explicitement appelées par lesautomates (par exemple la gestion de la file des timers dans SyncInterrupt , oucelle des threads dans Scheduler ), et d’autre part la définition et implémentationdes structures de données utilisées dans les automates (par exemple la classeTimerParam , utilisée en paramètre des signaux SetTimer et DelTimer ).

Code synchrone 900



Code externe 1.200

Le code de la machine d’exécution est composé de plusieurs librairies : libSync

est la librairie synchrone de base, qui permet la traduction d’un automate en unobjet C++, libEm ajoute une interface externe évoluée, StmEm traite de ce qui estpropre à nos automates (ajout/suppression des Threads ...) et SVP donne uneinterface utilisateur semblable à celle de CHORUS, et assure la communication avecle noyau. Leur taille est ici donnée en lignes.

Librairie synchrone (libSync ) 3.150Machine générique (libEm ) 2.000Machine spécifique StmEm 950SVP 1.380

3.4.5.2. Temps d’exécution

Nous disposons de deux bases de comparaison pour évaluer les performancestemporelles de notre système : le noyau CHORUS et l’ordonnancement utilisateurde Ph.Robin, qui offre des fonctionnalités proches du nôtre.

Les mesures peuvent porter sur l’ensemble des appels systèmes que nous avonsredéfinis, mais aussi sur le temps que prend un changement de contexte entredeux threads. Pour cela nous exécutons un programme qui effectue en boucle leréveil d’un thread qui s’endort dès qu’il est actif, en se basant sur le mécanisme deblocage/déblocage des sémaphores. Ainsi la mesure prend en compte le coût del’interface, de la gestion des timers (le blocage sur sémaphore étant à échéance), etle changement de contexte lui-même.

La deuxième mesure concerne le coût d’un appel à une fonctiond’ordonnancement. Le test consiste à invoquer 10 fois de suite l’opérationthreadResume() sur le thread courant, ce qui n’a aucun effet surl’ordonnancement, puisque ce thread est déjà actif. La valeur fournit donc une basede comparaison du coût des trois interfaces.

Sur Pentium 100MHz, avec un noyau Classix r2 ayant une horloge à 500Hz(période de 2ms), nous obtenons les temps suivants en micro-secondes (suivis dupourcentage par rapport au résultat du CHORUS natif) :

noyau CHORUS VP SVPChangement contexte 22 24 (109%) 1.070 (4863%)10 threadResume() 62 27 (44%) 5.700 (9193%)

Le premier test fait apparaître la performance de CHORUS pour changer decontexte, qui est plus rapide malgré le passage en mode système qu’il doiteffectuer. Le résultat du SVP est décevant, et le deuxième test met en évidence lacause : l’interface de notre système est très lente, car elle met en oeuvre unmécanique complexe pour chaque appel de la gestion des tâches, quel que soit lecode effectivement exécuté.



Les raisons de ces résultats sont liées au fait que l’environnement d’exécutiond’objet synchrone n’a pas été développé dans un souci de performance, l’objectifinitial étant avant tout de faire un système “qui marche”.

3.4.5.3. Optimisations

Pour améliorer les performances de notre gestion des tâches, il faut travaillersur plusieurs éléments, que nous allons maintenant examiner. Voici tout d’abordune décomposition du temps passé pour effectuer le changement de contexte. Ceschéma représente les durées d’exécution à différents niveaux de la réaction, lapremière ligne de valeurs montre la durée de la transition des automates desobjets synchrones ayant traité un signal; la deuxième est la durée de la séquenced’exécution de tous les objets synchrones, qui comprend la mise-à-jour de tousleurs signaux, et l’éventuelle transition; la troisième rappelle la durée totale del’opération. Signalons que la préparation du contexte destination est faite par latransition de Scheduler , et que l’activation effective de ce contexte est faite en finde réaction globale (elle est comprise dans la troisième ligne mais pas dans ledeuxième).

SysModeSyncInterrupt Sched TimerMgrInput

ModulesOutput

ModulesThreads

70 45 30

830

1070

Dans le schéma d’exécution des objets synchrones se trouve la plus grosse pertede temps : 830 micro-secondes sont utilisées pour uniquement 145 utiles (lestransitions des automates). Dans la version actuelle de notre environnementd’exécution synchrone, chaque objet, à chaque réaction, effectue la séquenced’opérations suivante :

1. mise à zéro des signaux de sortie

2. mise à zéro des signaux d’entrée

3. lecture des signaux d’entrée

4. parcours des signaux d’entrée, réaction de l’automate s’il y en a au moins unde présent

Ce qui veut dire que pour chaque réaction du micro-noyau tous les signaux enentrée et en sortie sont parcourus une fois, puis tous les signaux en entrée sontparcourus deux autres fois, une pour leur lecture, l’autre pour tester leur présence.Or, voici en récapitulatif du nombre de signaux :



Objets Entrée SortieSyncInterrupt 4 5SysMode 6 4Thread 30 15Scheduler 8 3TimerMgr 2 2Delay 2 2Total 22+n.30 16+n.15

où n est le nombre de threads dans le système.

Dans notre programme de mesure de performances nous avons trois threads :le principal (main ), qui lance les deux threads qui effectuent et mesurent lechangement de contexte. Nous avons donc 112 signaux d’entrée et 61 de sortie. Achaque réaction du micro-noyau, on traite ((112*3)+61)=397 fois un signal, quelque soit le nombre de signaux présents. En réalisant notre programme de mesuredifféremment, on peut mettre en évidence l’influence de ces traitements. Si lethread principal ne crée qu’un seul thread avec lequel il effectue lui même lechangement de contexte, la durée du changement d’un contexte tombe à 912 micro-secondes, soit un gain de temps de 15% en diminuant de 25% le nombre designaux.

C’est une aberration que l’on doit corriger. Il nous faut trouver une structured’exécution qui ne fasse pas dépendre le temps d’exécution du nombre de threads.Une réflexion avec F. Boulanger, le concepteur de la librairie synchrone, a amené àdéfinir une nouvelle structure d’exécution qui améliorerait radicalement lesperformances.

1. Avoir une structure d’exécution qui ne fonctionne plus par interrogation dela part des signaux d’entrée, mais par propagation des signaux de sortieprésents. Ainsi, à la fin de chaque réaction, les signaux de sortie présentsdiffusent leur valeur aux destinataires qu’ils ont enregistrés. Ceci évite letraitement des signaux absents, sans effet sur l’exécution.

2. Associer à chaque objet synchrone un booléen indiquant s’il possède unsignal présent en entrée, et donc s’il doit réagir. Ce booléen, initialement à“FAUX”, doit être mis à “VRAI” lors des affectations des signaux d’entrée del’objet, et réinitialisé en fin de réaction.

3. On ne remet pas à zéro les signaux des objets qui n’ont pas réagi, puisqu’ilsn’ont pas de signaux présents. La remise à zéro des signaux peut alors êtreeffectuée en fin de réaction, ce qui évite un second parcours des objets.

Des mesures ont permis de définir le temps nécessaire aux différents élémentsdes traitements, et d’évaluer le gain qui peut être obtenu par une telle mise-à-jour.Actuellement, on peut faire une approximation de la durée du changement decontexte par sémaphore à l’aide de la formule :

4,2.NO + 4,8.NE + 0,9.NS + R



NO est le nombre d’objets synchrones (21 dans notre exemple), NE le nombrede signaux d’entrée de tous ces objets (112), NS le nombre de leurs signaux desortie (61), et R la somme des durées des transitions (150).

La modification proposée pourrait modifier ce résultat, le coût des différentstraitements n’étant plus répercuté que sur les modules et signaux activés :

3,9.NSE + 1.NOR + 0,8.NSOR + 0,9.NEOR + R

NSE étant le nombre de signaux de sortie émis (6), NOR le nombre d’objetsayant réagi (5), NSOR le nombre de signaux de sortie de ces objets (27), NEOR lenombre de leurs signaux d’entrée (14). L’exécution des objets synchrones dureraitalors à peu près 210 micro-secondes (au lieu de 830).

Un autre aspect de l’optimisation concerne l’interface avec le mondeasynchrone. A chaque signal externe de notre système (il y en a 29 dans notreexemple) est associé un objet d’interface. Il dispose d’un signal, utilisés pourmémoriser une valeur à destination des automates s’ils sont en entrée, ou dumonde asynchrone s’ils sont en sortie. Les objets d’interface d’entrée reçoivent unedonnée du monde asynchrone, et lorsque le micro-noyau synchrone est stimulé ilsrecopient cette valeur dans leur signal de sortie et le mettent à la disposition desautomates. Réciproquement, les objets d’interface de sortie affectent leur signal enfin de réactions des automates, et l’émettent à destination du monde asynchrone.Ces objets d’interface permettent des modes de communications variés, mais nousn’avons pas à nous préoccuper de cela, puisque nous ne communiquons que parmémoire partagée. Ils permettent aussi de recevoir des signaux pendant uneréaction, le signal ne devant pas être visible par la réaction en cours puisqu’elledoit avoir une vision statique de son environnement pendant toute sa réaction.Nous n’avons pas besoin non plus de cette fonctionnalité, puisque nous nousplaçons dans le cadre d’une machine monoprocesseur, et qu’il n’y a pas deparallélisme ‘logiciel’ à notre niveau, puisque c’est notre système qui le fournit.Seules les interruptions peuvent survenir pendant une réaction, mais lesinformations les concernant sont stockées dans des structures de donnéesparticulières. Enfin le troisième rôle de ces objets est de donner une interfaceexterne facile à utiliser pour la transmission d’un signal, avec la méthode emit() ,pour les modules en entrée, et get() pour ceux en sortie. La modification de lastructure d’exécution que nous avons proposée va justement amener à donner uneinterface de ce type aux signaux des automates, puisque l’on passe d’un système descrutation par les entrées à une propagation par les sorties. Les signauxposséderont donc une méthode set() pour modifier leur valeur, ce qui correspondau emit() . Ils invoqueront cette méthode sur les objets auxquels ils serontconnectés, informant ainsi le monde asynchrone des signaux présents, alors quedans la méthode actuelle, pour avoir cette information, il aurait fallu scruter tousles signaux de sortie. L’ensemble de ces constatations met en évidence l’inutilité deces objets d’interface, qui peuvent donc être supprimés. Le gain qui sera obtenupar cette modification n’est pas égal à la différence entre la durée totale de laréaction du micro-noyau synchrone et celle de l’exécution des objets synchrones,car cette différence inclut aussi des opérations qui ne seront pas supprimées, tellesque le verrouillage/ déverrouillage de la machine d’exécution, le changement de



contexte, la vérification de la validité des paramètres de l’appel à la gestion destâches, la scrutation des interruptions... Il restera un coût fixe de l’ordre dequelques dizaines de micro-secondes (20 à 30).

Les deux modifications proposées permettront de faire chuter la durée duchangement de contexte de notre exemple de 1070 à une valeur de l’ordre de 235micro-secondes. Malgré l’importance de cette réduction, la valeur reste dix foissupérieure à celle de CHORUS. D’autres améliorations sont possibles, quipermettront des gains moins importants, mais qui, cumulés, apporteront des effetsintéressants. Ils portent sur la durée des transitions des automates, qui devientl’élément le plus coûteux si les améliorations précédentes sont réalisées. Nous lesprésentons ici sans donner d’évaluation du temps économisé, car la réflexion et/oules études les concernant ne sont pas encore suffisamment complètes.

Les communications multiplexées, entre les threads et les objetsd’ordonnancement et de gestion du temps, nécessitent une gestion des valeurs dessignaux permettant la mémorisation de données multiples. Par exemple le signalActive , en entrée de l’ordonnanceur, peut être émis par plusieurs threads dans lamême réaction. Chacun émet ce signal avec en valeur son identificateur. Lorsquel’ordonnanceur reçoit Active , sa valeur doit contenir l’ensemble des identificateursdes threads qui l’ont émis dans la réaction courante. La version actuelle dusystème utilise des listes chaînées dynamiques pour les valeurs de ces signaux. Cetype de gestion prend du temps : il faut allouer dynamiquement les éléments quisont insérés dans la liste, une copie de la valeur de ce signal implique l’allocationet la création de l’ensemble de la structure. Ce mécanisme est d’autant plus lourdque les éléments sont gros : la valeur des signaux SetTimer et DelTimer , eux aussimultiplexés, contient non seulement l’identificateur du thread émetteur, maisaussi la date de l’attente programmée. Cette méthode peut avantageusement êtreremplacée par une structure plus performante : il serait possible de ne pas utiliserles signaux pour véhiculer ces informations, mais de passer par une zone dedonnées partagée, gérée à l’aide d’un tableau de pointeurs. La structure destableaux est plus rapide, puisqu’elle ne nécessite pas l’allocation dynamique demémoire, et les pointeurs permettront de ne jamais recopier de donnée.L’utilisation des pointeurs doit se limiter aux données de taille importante, carl’indirection qu’elle implique pour l’accès aux informations peut s’avérer être pluscoûteuse que la recopie pour des données de quelques octets. Le signal nevéhiculerait alors que l’information relative à l’occurrence de l’événement, l’accèsaux informations étant réalisé par appels de procédures, ou même directementpour les données simples. Cette approche ne fait perdre aucune propriété ausystème, et en particulier n’altère pas les preuves que l’on peut en faire, puisquecelles-ci ne porte que sur l’occurrence des signaux, et sur leurs valeurs.

La dernière version du compilateur ESTEREL (v4_45) permet de générerdifférents types d’automates, et en particulier des automates considérablementplus petits que les versions précédentes. Ces automates ne possèdent que deuxétats, ce qui évite la duplication de code qui se trouvait dans différents états (enparticulier les tests de présence des signaux). Ceci offre la possibilité de compileren parallèle synchrone des modules qui ne pouvaient pas l’être en raison de lataille excessive de l’automate qui était généré. Une autre organisation du système



peut alors être envisagée, qui permettra de réduire le nombre d’automates et designaux. La contrepartie de cette méthode est un accroissement de la durée destransitions des automates, des mesures permettront de savoir lequel des deuxeffets est le plus important.

Le dernier point proposé comme sujet d’optimisation concerne la réalisation destransitions des automates. Ces derniers sont pour l’instant codés sous forme detableaux, dont chaque élément fait référence à une action. L’exécution de latransition consiste à parcourir ce tableau, et à soumettre le code de l’actioncourante à une procédure qui exécute l’action correspondante. L’expansion del’automate sous forme de code directement exécutable permettrait d’éviter unnombre important d’appels de procédures et le parcours du tableau. Le code généréserait plus gros, car certaines actions seraient dupliquées, mais la duréed’exécution serait diminuée.

3.5. Conclusion

Nous avons montré dans ce chapitre comment la gestion synchrone des tâchespeut être mise en oeuvre. Ce travail s’est révélé plus complexe que prévu. Lesdifficultés ont mis en évidence l’importance de l’environnement de développementet d’exécution qui doit être associé à la programmation synchrone. Pour que celle-cisoit intéressante et utilisable, il est primordial de disposer d’outils en rendantl’implantation facile.

Les principaux problèmes auxquels nous avons été confrontés sont lessuivants :

• Il est difficile de gérer des configurations dynamiques et de taillesimportantes. Il nous a fallu procéder à un découpage de la gestion destâches en plusieurs objets synchrones, compilés séparément. Ceci estpénalisant car d’une part les outils de vérifications dont nous disposons nepeuvent porter que sur du code compilé en un seul bloc, et d’autre part celarend nécessaire une machine d’exécution gérant des séquences de réactions,ainsi que des mécanismes de communications entre objets synchrones. Desétudes sont actuellement en cours, afin de permettre la vérification formellede comportements d’un système d’objets synchrones interconnectés.Concernant les tailles des automates, le dernier compilateur ESTEREL tendà les réduire, autorisant des compositions de modules jusqu’alorsimpossibles.

• Les communications complexes (multiplexage/démultiplexage) utiliséesdans notre système ne sont pas prévues dans la librairie synchrone de base.Nous avons dû écrire le code permettant de les gérer, et le code C++ générépar le compilateur ESTEREL doit être modifié pour pouvoir les prendre encompte. Ceci devrait faire l’objet d’un ajout à la librairie synchrone.

• Les performances se sont révélées décevantes. Le schéma d’exécution desobjets synchrones, la quantité d’objets synchrones présents (liée au premier



point) et le codage de l’automate en sont les principales causes. Nous avonsproposé des solutions dans chacun de ces domaines.

Une fois ces améliorations apportées à l’environnement d’exécution des objetssynchrones, l’implantation native de notre gestion des tâches pourra êtreenvisagée, soit en remplacement d’une autre dans un noyau existant, soit dans unnouveau noyau. Cette dernière solution est évidemment la plus intéressante : enétendant le travail de réécriture synchrone à d’autres éléments du noyau, onobtiendrait un noyau synchrone natif, dont on aurait une spécification formellecomplète.



Chapitre 4.

Exécutif synchrone réparti

Nous avons présenté, dans les chapitres précédents, une gestion des tâchescentralisée. Nous allons maintenant considérer une configuration dans laquelle unensemble de sites interconnectés exécutent chacun notre gestion synchrone destâches. Nous montrons dans ce chapitre comment la synchronisation de cesgestions de tâches permet de constituer un exécutif synchrone réparti, offrant unebase de synchronisation pour le développement d’applications réparties.

4.1. Les modèles des objets réactifs répartis

Un système d’objets réactifs est un ensemble d’objets réactifs interconnectés,c’est-à-dire se communiquant certains événements. Nous avons montré, dans lechapitre précédent, comment implémenter un tel système dans un cadrecentralisé. Toutefois un grand nombre de systèmes informatiques sont répartis,soit en raison de la disparité géographique des éléments qu’ils contrôlent, soit dansun souci de performance (mise en parallèle) et/ou de sécurité (duplication). Pourconserver le déterminisme du système, il est nécessaire de définir une machined’exécution permettant de reconstituer le synchronisme d’un groupe d’objetsréactifs répartis interagissant.

La répartition des objets réactifs introduit deux nouveaux éléments : ilspeuvent s’exécuter en parallèle, et les communications ont des durées importantes.Alors que le premier point diminue la durée des réactions, le second, généralementd’un ordre supérieur, l’augmente considérablement. Cette situation rendnécessaire la définition d’un nouveau modèle prenant en compte la non-simultanéité de l’occurrence d’un événement aux différentes interfaces des objetsdans lesquelles il apparaît. En d’autres termes, il est nécessaire de considérerl’intervalle de temps entre l’émission d’un événement par un objet et sa réceptionpar son ou ses destinataires.

Il est possible de définir différentes sémantiques de l’exécution répartie d’unsystème d’objets réactifs, suivant le degré de synchronisation qui les unit, et lespropriétés de leur environnement.

Exécutif synchrone réparti 111


Concurrence asynchrone

Le modèle le plus simple considère un ensemble de zones synchrones,constituées d’objets réactifs situés sur un même site. Les communications entre leszones sont de durées quelconques, éventuellement non bornées. L’absence demécanisme de synchronisation et l’indéterminisme des communications conduit àune exécution parallèle et indépendante des objets situés dans des zonessynchrones différentes. Ce modèle peut être suffisant dans le cas où il n’existe pasde notion d’état global du système, c’est-à-dire où les fonctions de contrôle deszones synchrones sont purement locales, bien qu’elles tiennent compted’événements distants. Ceci est par exemple le cas pour un système de contrôle devanne d’un barrage hydraulique, qui prendrait en compte les informations enprovenance de capteurs distants pour réguler son débit. Dans cette configuration,aucune synchronisation n’est nécessaire entre les capteurs et la vanne, même si laperformance du système est fonction de la vitesse des communications.

Ce modèle n’impose aucune contrainte à son environnement, autre que cellelocale qui exige que la fréquence des événements ne soit pas supérieure auxpossibilités de traitement de la zone synchrone concernée. Il n’est utilisable quepour certains types d’applications, dont sont exclus les traitements nécessitant desgaranties comportementales ou temporelles.

Synchronisation des réactions

Pour bénéficier du déterminisme de l’approche synchrone dans un systèmeréparti, il est nécessaire de synchroniser les réactions des objets réactifs quelle quesoit leur localisation. Pour cela les différentes zones synchrones doivent partagerla même notion d’instant, dont la suite d’occurrence définit un temps logiqueréparti. Ainsi, chaque événement pourra être daté de façon unique par l’ensembledu système, et un événement communiqué entre les zones synchrones sera assuréd’être traité “simultanément”, au sens de l’horloge logique, par tous les objetsdestinataires.

Une telle synchronisation est obtenue en déterminant une durée fixe pour lescommunications. Le synchronisme ainsi obtenu n’est plus celui de la sémantiqued’ESTEREL. En effet, ce dernier suppose une diffusion instantanée des signaux : unsignal émis dans une réaction est présent dans la même réaction pour tous lecomposants du système. Nous définissons une nouvelle sémantique, dans laquelleun signal émis à un instant est perçu par tous les objets destinatiares à un instantultérieur.

On pourra par exemple définir une durée de communication égale à une unitéde temps logique. Un événement produit par un objet réactif sera alors disponibleà l’instant suivant sur l’ensemble du système. La durée de l’intervalle entre deuxinstants sera alors au moins égale à la durée maximum de communication entredeux zones. Ceci n’est évidemment possible que si le média assure un délai borné.

Les communications à l’intérieur d’un système réparti peuvent être de duréestrès inégales entre les zones synchrones. Dans le cas, par exemple, d’un système de

112 Exécutif synchrone réparti


contrôle d’un satellite, plusieurs zones au sol peuvent échanger des donnéesrapidement, mais tout transfert avec le satellite est beaucoup plus long. Il est alorspénalisant de restreindre l’ensemble du système à cette durée maximum. Celapeut en particulier rendre invalide l’hypothèse d’instantanéité, les événements nepouvant plus être traités au rythme de leur occurrence. Pour pallier ce problème,on définit des canaux de communication de durée supérieure à une unité du tempslogique.

En conclusion, deux conditions sont nécessaires pour qu’un système réactifréparti soit déterministe :

1. Il faut disposer d’un temps logique commun à toutes les zones synchrones;ceci implique que les réactions soient synchronisées.

2. Les communications doivent avoir une durée fixe mesurable à l’échelle dutemps logique; ceci n’est possible que si ces communications ont un délaiborné.

Etant donnée notre configuration, constituée d’un groupe d’ordinateursconnectés sur un réseau local, nous utiliserons dans la suite de notre étude unesynchronisation utilisant uniquement des canaux de communication prenant uneunité de temps. Ceci est l’objet du modèle synchrone faible que nous avons choisi,et qui sera détaillé dans ce chapitre.

Ancrage du temps logique dans le temps physique

Les intervalles de temps entre les instants de l’horloge logique ne sont pasnécessairement de durées régulières. Toutefois, pour la plupart des applicationstemps-réel, il est essentiel qu’elle le soit. C’est en particulier indispensable si l’undes signaux d’entrée du système réactif est un événement temporel, un signald’horloge périodique par exemple. La valeur de ce signal n’a un sens que si lesystème assure une corrélation entre la datation physique de ce signal, et celle dela réaction qui la traite.

L’ancrage du temps logique dans le temps physique consiste donc à fixer unedurée des intervalles de temps entre les instants de l’horloge logique, mesurée enunité de temps physique. Cela revient à garantir une exécution périodique desréactions du système. Cette réalisation fera l’objet du modèle d’exécution que nousallons développer.

4.2. Le modèle synchrone faible

Nous présentons tout d’abord le modèle de notre système sous deux aspects :les modèles sémantique et d’exécution. Puis nous présenterons son intégrationdans notre gestion des tâches.

4.2.1. Le modèle sémantique

Le langage ESTEREL est basé sur une sémantique opérationnelle synchroneforte. Celle ci spécifie qu’un objet réactif OR, dans l’état ORi résultant de sa ième



réaction, réagit de façon déterministe et instantanée à l’événement d’entrée I enproduisant l’événement de sortie O et en passant dans l’état ORi+1. Ceci est noté :

OR ORiO

Ii → +1

Considérons maintenant un système d’objets réactifs concurrentsS=(OR1||...||ORn). Chacun des objets ORj se comporte conformément au modèlesynchrone fort, mais l’ensemble du système est basé sur une sémantiquesynchrone faible :

1. Tous les objets partagent la même horloge logique.

2. Au ième top de cette horloge, tous les objets prennent l’événement présent àleur entrée et réagissent en conséquence. Les événements qu’ils produisentne sont disponibles pour les objets concurrents qu’au top i+1.

On note

S O OR ORi i i in= ×( ,..., ){ }1

l’état interne du système au top i, où Oi est l’ensemble des événements produitspar la réaction des objets au top précédent. On note :

S SiI

O

ii

i+

⇒ +1

1

pour traduire qu’au ième top, le système dans l’état Si (contenant déjà lesévénements de la réaction précédente), soumis à l’événement Ii en provenance del’environnement, réagit en émettant l’événement Oi+1, exploitable à i+1, et devientSi+1 à i+1.

Dans cette réaction, chaque objet du système exécute la transition :

OR ORij O

O I ijj

i i

→∪ +1 avec Oi+1 = O1 ∪...∪ On

Les règles définissant d’une part les réactions des objets synchrones, et d’autrepart les réactions du système sont déterministes, la sémantique du systèmed’objets réactifs concurrents est donc déterministe.

4.2.2. Le modèle d’exécution

La sémantique du synchronisme faible repose sur la durée des réactions qui estexactement égale à une unité de temps, et la disponibilité des événements produitspar une réaction à l’occurrence de la réaction qui la suit. Il ne peut donc seproduire aucun événement (ou au moins ne sont ils pas observables) entre deuxtops : le modèle présente une base de temps clairsemée, les événements ne pouvantsurvenir que dans des intervalles de temps déterminés. Cette notion, introduite



par H. Kopetz [KOP92], s’oppose à celle base de temps dense, dans laquelle lesévénements peuvent se produire à tout moment. L’accord entre les objets réactifspour définir quand les événements peuvent se produire fait l’objet d’unesynchronisation répartie. L’objet du modèle d’exécution est de définir comment estréalisée cette synchronisation.

L’objectif de cette synchronisation est de s’assurer qu’à chaque stimulation desobjets réactifs répartis, chaque objet a réagi à la stimulation précédente enémettant éventuellement un événement, et que les autres objets l’ont bien reçu(respect du modèle sémantique). D’autre part nous souhaitons idéalement que lesobjets réagissent “en même temps” (respect de la simultanéité), c’est-à-dire qu’unobservateur extérieur possédant un référentiel de temps unique puisse constaterque les dates de ces réactions sont toutes comprises dans un intervalle de tempslimité (et connu). La taille de cet intervalle et la fréquence des réactions sontfortement dépendantes d’une part des performances matérielles du système, maisaussi de celles du protocole. Nous allons présenter une approche qui permet deminimiser et borner ces deux valeurs.

Examinons des protocoles classiques généralement utilisés pour traiter ce typede synchronisation. Ils reposent sur la diffusion d’un top d’horloge, et sonacquittement :

• Solution 1 (algorithme à vague) : Un site maître diffuse un top horloge, ilattend l’acquittement de l’ensemble des objets réactifs pour déterminer letop suivant. Le nombre de messages émis est relativement important : 2n (ntops, n acquittements). Cette méthode est peu résistante aux fautes,puisque tout repose sur un site maître. Il est bien sûr possible de disposerd’un protocole de détection de panne de ce site, et de réélection d’un autre,mais ce type de gestion est coûteux. La simultanéité du démarrage desréactions n’est pas assurée, elle dépend exclusivement du protocole dediffusion.

• Solution 2 (algorithme phasé) : Chaque objet réagit, et diffuse sonacquittement à tous les autres objets. Pour cela chacun dispose de la liste detous les objets présents, et attend leur acquittement avant d’exécuter unenouvelle réaction. Cette méthode élimine le “talon d’achille” qu’était le sitemaître de la solution précédente, mais le nombre de messages devient trèsimportant : n2. Et l’ajout d’un nouvel objet nécessite une mise à jour dedonnées chez l’ensemble des objets. D’autre part la simultanéité n’esttoujours pas assurée, puisque le début d’une réaction dépend uniquementde la date d’arrivée du dernier acquittement, sur laquelle on ne dispose pasde garantie.

H. Kopetz [KOP92] a montré comment réaliser ce type de synchronisation en sepassant de ces protocoles coûteux (en termes de temps et de ressources). Il fautpour cela utiliser les connaissances du comportement temporel du système pourdéterminer a priori une grille de temps définissant les instants auxquels les objetsvont pouvoir réagir. Plus le système a un comportement temporel prévisible, pluscette grille peut être optimale, c’est-à-dire moins il y aura de temps inutilisé entre



les réactions. L’intérêt de cette approche se manifeste particulièrement quand lesystème est suffisamment prévisible pour que les performances soient au moinségales à celles des protocoles classiques en éliminant leur coût, laissant ainsi plusde ressources (CPU, réseau...) pour les autres éléments du système. Aucunmessage n’est nécessaire (en dehors de ceux de la synchronisation d’horloges), et lasimultanéité est clairement définie par un intervalle. Cette méthode ne repose passur un site maître, ce qui évite d’avoir à ajouter des protocoles d’élection du sitemaître, et de détection de ses fautes.

Nous nous basons pour cela sur une synchronisation d’horloges de granularitégk. A chaque tick, les valeurs des horloges locales sont incrémentées de gk, cettevaleur étant mesurée à l’aide d’une horloge de référence z (de granularitésupérieure). Le coût de cette synchronisation n’est pas directement imputable auprotocole que nous décrivons, puisque sa présence est de toute façon requise dansun système réparti temps-réel. Le nombre de messages émis est de toute façonmoindre que celui des algorithmes d’itérations répartis, puisqu’il est de l’ordre de npendant les phases de resynchronisation, mais celles-ci ne se produisent que demanière éparse. Nous appelons Π la précision de la synchronisation, qui est l’écartmaximum entre deux horloges locales quelconques :

Π = MAX (∀ i, ∀ k, ∀ l | z(ki) - z(li) | )

où z(e) désigne la date sur l’horloge de référence de l’événement e, et ki et li lesévénements correspondant à l’occurrence du ième tick des horloges locales k et l.

Il est possible d’imaginer une nouvelle mesure abstraite du temps, un tempsglobal, de granularité supérieure à celle des horloges synchronisées, et qui, si sesticks sont correctement placés, donneront une vision unique du temps sur tous lessites. Pour que l’écart maximum entre deux mesures du temps global sur deuxsites ne soit jamais supérieur à 1, il est nécessaire que sa granularité gg respecte

gg > Π

klm

Temps global,

temps réel

Horloges locales, de granularité g, précision Π

Π

= 2,5g

• • • • • • • • • •• • • • • • • •

• • • • • • • • • ••

Kde granularité 3g

Relation entre les horloges locales et le temps global

Dans l’exemple de la figure ci-dessus, la précision de l’horloge est Π = 2,5.g. Onprend un temps global de granularité supérieure, ici gg = 3.g. Chaque horlogeproduit donc tous les trois ticks de son horloge locale un tick du temps global. Π



représente l’intervalle de temps pendant lequel toutes les horloges localesproduisent le tick correspondant au même tick du temps global. La succession desintervalles K = gg-Π constitue une base de temps clairsemée, si tous lesévénements du système ont leurs occurrences contraintes à ces intervalles, alorsils pourront être datés avec la même estampille globale sur tous les sites.

Les événements sont communiqués d’un site à un autre par messages véhiculéssur le réseau. Nous supposons l’existence d’une borne dmax sur la durée d de cescommunications. Notons que cette valeur doit prendre en compte non seulement letransit de l’information sur le réseau, mais aussi le traitement des messages surchaque machine. Lorsqu’un site i communique un événement e à ti(e), il doitattendre ti(e)+dmax pour être sûr que tous les sites l’ont reçu. Si i peut émettre esur une base de temps dense, les destinataires peuvent dater la réception avec desvaleurs différentes.

site i

site j

t(e) t(e)+1

Π

e

t(f) t(f)+1

f

Erreurs de datations si la base de temps est dense

Il peut se produire deux situations indésirables :

• Le site j reçoit e trop tôt (à t(e)-1), car la communication a été rapide,inférieure à l’imprécision de l’horloge. Pour éviter ce phénomène, il ne fautpas envoyer e avant t(e)+Π.

• Le site i reçoit f trop tard (à t(f)+1), car le temps global a avancé d’une unitéentre l’émission et la réception de f. Pour éviter cela, il faut prendre encompte l’imprécision sur la synchronisation des horloges, mais aussi letemps maximum de communication : il ne faut pas envoyer f après t(f)+1-Π-dmax.

Il est donc possible de déterminer une datation globale des événements, sanséchange de messages protocolaires ni ajout de données dans les messages, si letemps repose sur une base clairsemée, constituée d’intervalles de période gg et dedurée

K = gg - 2.Π - dmax



Π

site i

site j

t(e) t(e)+1dmax

Π

e

t(f)t(f)+1

f

K

Datation uniforme grâce à la base de temps clairsemée

La granularité gg de l’horloge globale doit donc être choisie de telle sorte que Ksoit d’une durée suffisante pour pouvoir exécuter les traitements qui doivent s’yproduire.

Cette notion de temps global nous donne un support pour l’exécution d’objetsréactifs répartis. Les événements datés t sont traités par la première réaction dedate supérieure à t. Cette réaction produit des événements, qui sont datés etdiffusés uniquement à l’intérieur d’un intervalle K. Ils seront donc datésuniformément par tous les sites, et disponibles pour les objets réactifs au tickglobal suivant immédiatement ce K. Tous les objets réactifs disposent alors d’unhistorique d’événements identique. D’autre part la simultanéité (à Π prêt) estobtenue en convenant d’un instant particulier à l’intérieur de gg pour le démarragedes réactions : nous pourrons prendre par exemple le tick lui même, ce qui laisseraune durée Π+K pour exécuter la réaction et émettre (à partir de t+Π) l’événementproduit à la même date.

4.3. Application à la gestion des tâches

Examinons comment utiliser le modèle que nous avons définis pour exécuter etsynchroniser des gestions de tâches synchrones s’exécutant sur différents sites.

4.3.1. Comportement temporel

Le modèle que nous venons de présenter permet de constituer une base detemps répartie de période gg avec une imprécision connue. Nous appliquerons cettebase de temps à l’exécution du micro-noyau synchrone en définissant les règlessuivantes :

• K doit être défini de telle sorte qu’il permette à toute réaction du micro-noyau de s’exécuter complètement et d’émettre les événements qu’elle aproduits. Ceci assure la conformité au modèle sémantique, en garantissantque toute réaction commençant à une date t aura non seulement terminécette réaction à t+1, mais aussi qu’à cette date tous les événements qu’elleaura produits seront disponibles en entrée de l’ensemble des micro-noyaux.Dans la version actuelle, K est une constante définie pour une instance dusystème, en fonction de ses performances.



• Chaque micro noyau réagit en début de période gg, ce qui assure lasimultanéité. Si à cet instant le micro-noyau ne possède aucun événementpertinent en entrée alors il n’y aura pas de réaction.

• Un nouveau micro-noyau s’insérant dans une exécution en cours disposelocalement de toutes les informations nécessaires pour définir sa périoded’exécution : Π lui est fourni par le module de synchronisation des horloges,dmax par le gestionnaire de communication, et K est une constante connue.De plus, pour qu’il sache quand démarrer, on fixe une date initialecommune égale à la valeur 0 de l’horloge synchronisée locale. Ainsi, lenouveau micro-noyau peut connaître à un instant i la valeur de l’horlogeglobale en effectuant une division entière de son horloge locale par lagranularité de l’horloge globale : z(i) = E(zk(i)/gg). La date de l’horlogelocale à laquelle doit commencer la réaction suivant l’instant i est :(z(i)+1).gg.

• Un micro-noyau terminant son exécution n’a aucune action particulière àexécuter. Les valeurs de K, Π et dmax, dans certaines configurations,peuvent varier en fonction du nombre de sites connectés. Nousn’envisageons pas pour le moment de modifier dynamiquement la périodede l’horloge globale; les valeurs des paramètres servant à la calculer serontdonc les maximums, correspondant à la configuration la moins performante.Notre but n’est pas d’obtenir de la performance et de la dynamicité, ilfaudra ici choisir entre ne pas faire de système (trop) dynamique, auquelcas on pourra calibrer précisément la période, ou bien un système trèsdynamique dans lequel la période sera la plupart du temps trop grande, enprévision des charges importantes possibles.

4.3.2. Les communications entre les tâches

La gestion synchrone centralisée des tâches que nous avons présentén’intégrait pas de mécanisme de communication entre les tâches. Un thread n’yavait connaissance que des threads s’exécutant localement, c’est-à-dire dans lemême SVP. La répartition rend nécessaire d’adjoindre aux mécanismes de base unoutil de communication entre les threads. C’est cet outil que nous allonsmaintenant examiner.

L’objectif n’est pas ici de mettre en oeuvre un mécanisme complet et complexe,il s’agit d’offrir une fonctionnalité permettant des communications etsynchronisations entre threads de différents espaces d’adressage, qui mette enévidence l’intérêt et le bon fonctionnement de la synchronisation de l’exécutifsynchrone réparti.

Du coté de l’émetteur, la communication se fait par une émission non bloquanted’un message. Du coté du récepteur, l’attente de message est bloquante, avec uneéchéance. Si celle-ci expire avant l’arrivée d’un message, le récepteur est réveilléavec un code d’erreur. Le système assure la transparence à la localisation.



Un message possède un en-tête, décrivant sa destination et son origine. Unthread est défini de façon unique dans l’ensemble du système par unidentificateur. L’origine du message est l’identificateur du thread qui l’a émis, sadestination est soit l’identificateur d’un thread, soit un code signifiant que lemessage doit être diffusé à tous les threads. En plus de ces deux informations, l’en-tête contient la date d’émission du message, et un code permettant au récepteurd’identifier le type du message qu’il reçoit. Cette information lui sert en particulierà décoder le corps du message, qui est transmis en tant que bloc de données dontla taille est indiquée dans le message.

Un message émis à une date t est toujours reçu par son destinataire à la datet+1. Si ce dernier est bloqué en attente de cet événement, alors il est réveillé, sinonle message est mémorisé dans une file propre au destinataire, en attente d’unelecture future de la part de l’application. Un thread peut recevoir simultanémentplusieurs messages, dans le cas où plusieurs threads, à la même date, lui envoientun message. Tous les messages émis à la même date sont chaînés et accessibles enune seule lecture de la part de l’application. Par contre, des messages de datesdifférentes ont été mémorisés dans la file de réception d’un thread, alors il faudraautant d’invocation de lecture que de dates de messages pour lire l’ensemble desmessages.

4.3.2.1. Intégration dans le micro-noyau synchrone

Deux modules synchrones sont ajoutés à l’architecture du micro-noyausynchrone pour gérer les communications : thMsg , qui traite les messages auniveau des threads, et SyncComm, qui traite l’interruption réseau signalant laprésence d’une donnée. Le schéma suivant montre où s’insèrent ces modules dans

MessageIn

MessageOut

UserSystem

Hardware

SendMessage,GetMessage

Message

Network

Trap(1)

InterruptMgr

Interrupt

Thread

ThMsg

NetIntSyncComm

Les modules thMsg et SyncComm dans le micro-noyau synchrone



l’architecture du système présentée au chapitre 2.

A chaque module de contrôle de thread est associé un module decommunication thMsg , qui a pour rôle de :

• recevoir les demandes d’émission de messages en provenance del’application (signal SendMessage ) et de les communiquer (signalMessageOut ) au gestionnaire de communication de base.

• recevoir les messages en provenance du gestionnaire de réseau (signalMessageIn ), et de les mettre en file si le thread ne les attend pas.

• recevoir les demandes de messages de l’application (signal GetMessage ). Siun message est disponible (soit parce qu’il vient d’arriver, soit parce qu’ilétait en file), il lui est retourné immédiatement (signal Message ); sinon lethread est mis en attente en coopération avec le module thSleep , quicontrôle ce sous-état du thread.

Au niveau bas du système, le module SyncComm traite l’interruption réseau(numérotée 1 dans le schéma). Comme l’interruption horloge, son traitement estsynchrone, c’est-à-dire qu’il est exécuté dans la réaction ayant reçu le signald’interruption, et non dans un gestionnaire d’interruption asynchrone. C’est lemodule InterruptMgr qui traduit le signal Trap(1) en signal NetInt . A chaqueoccurrence de NetInt , SyncComms lit les informations du réseau ayant produit cetteinterruption, et, si elles contiennent des messages, émet à destination des threadsconcernés un avis (signal MessageIn ) pour qu’ils prennent en compte le ou lesmessages qui leurs sont destinés. Le module SyncComms est donc un distributeur demessages.

Cette communication introduit la notion de signal réparti. En effet on peutconsidérer le micro-noyau synchrone comme étant un support d’exécutionpermettant la répartition du signal SendMessage . On peut représenter lescommunications entre les threads par le schéma suivant :

SendMessage

Message

Message

Thread 2

Thread 1

Thread 3

Exécutif réparti

Traduction des signaux SendMessage en Message

Le signal SendMessage est converti par le micro-noyau synchrone en unensemble de signaux Message en entrée des destinataires. Cette mise en relation



est répartie, puisque l’émetteur et les destinataires peuvent être sur des sitesdifférents, le micro-noyau assure la transparence à la localisation.

A un niveau plus bas dans le système, cette correspondance est réalisée par lesoccurrences de messages MessageOut et Trap(1) .

4.3.2.2. Intégration dans les SVP

Les threads sont identifiés de façon unique par l’identificateur unique du SVPdans lequel ils se trouvent (fourni par le noyau CHORUS), plus une identificateurunique local (un entier incrémenté à chaque demande d’identificateur).

Les messages sont transmis d’un espace d’adressage à un autre à l’aide des IPCCHORUS. Chaque SVP crée une porte de communication et l’inscrit dans le groupede portes SVP_GRP, connu de tous les SVP. Un thread noyau est créé, qui se met àl’écoute de cette porte, et positionne un booléen dans l’espace partagé avec le noyaulorsqu’une donnée est présente. Le noyau, détectant la modification de cettevariable, signale l’occurrence de l’interruption 1 au SVP, par la même techniqueque n’importe quelle interruption. Le module SyncComm est alors activé, il provoqueune lecture des données disponibles sur la porte.

Tout message émis par un SVP est diffusé sur le groupe SVP_GRP, il est doncreçu par l’ensemble des SVP, même si le destinataire était un thread local. Dansune version future, il pourrait être intéressant de n’émettre un message, quandc’est possible (c’est à dire quand le message n’est adressé qu’à un thread), que versun seul SVP. Ceci permettrait de diminuer la charge du réseau et des modules deréception, mais n’augmenterait pas la vitesse du système : conformément aumodèle sémantique un message est toujours communiqué en exactement une unitéde temps global.

4.3.2.3. Interface utilisateur

L’interface utilisateur des communications se résume à deux opérations. Letype Msg est un pointeur vers une structure contenant l’en-tête et la référence ducorps d’un message.

• Emission :

int svp_sendMessage( Msg mess );

Opération non bloquante permettant l’envoi d’un message. La valeur entièreretournée est un code informant de la bonne exécution de l’émission (et non de laréception).

• Réception :

int svp_getMessage( Msg &mess, int delay );

Opération bloquante permettant la réception d’un message. Le paramètredelay est le nombre d’unités de temps maximum pendant lesquels l’application



accepte d’attendre le message. La valeur entière retournée est un code indiquant siun message a été reçu, et sinon pourquoi (expiration d’échéance, annulation...).

4.3.3. Le déclencheur de réaction

Pour faciliter le développement de différentes politiques de déclenchement deréactions, nous avons séparé cette fonction du reste de la machine d’exécution. Unmodule déclencheur (Trigger ) a en charge l’initiation de la réaction du micro-noyau synchrone, en fonction des informations qui lui sont fournies sur lesoccurrences des signaux. Il contrôle aussi la diffusion des signaux répartis, eninitiant la communication sur le réseau du signal MessageOut .

L’interface générique d’un déclencheur comprend les opérations suivantes :

• EventIn() : Appelée à chaque fois qu’un signal est positionné en entrée dumicro-noyau.

• WaitReaction() : Une réaction du micro-noyau doit avoir lieu entrel’invocation de cette opération et son retour. Ceci est particulièrement utilelorsque l’on attend un signal en réponse à un autre que l’on vient d’émettre.Par exemple si un thread émet le signal Sleep à destination du micro-noyau (pour se mettre en attente d’un événement), il est nécessaire qu’il aitété traité, et donc qu’une réaction ait eu lieu, lorsqu’il reprend la main pourlire le signal Awake l’informant de son réveil. Plus généralementWaitReaction est appelé après chaque signal que nous avons qualifié destimulant, parce qu’ils peuvent provoquer une modification du contexted’exécution. Rappelons ici qu’à la fin d’une réaction, il est nécessaire detester si des interruptions se sont produites en cours de réaction, et de lestraiter immédiatement le cas échéant. Ceci est réalisé par l’appel àl’opération CheckNewInterrupt , qui teste si une interruption s’est produite,et dans ce cas la positionne en entrée de la machine d’exécution.

• EventOut() : Cette opération déclare l’occurrence d’un signal réparti, elleest appelée par la procédure associée au signal MessageOut . Elle positionneun booléen (outputPresent ) à vrai.

• Suspend() : Lorsque le SVP n’a plus aucun traitement a effectué, le threadidle le rend inactif en invocant cette méthode. Elle permet à chaquepolitique de prendre en compte les événements qui détermine le réveil duSVP.

D’autre part les déclencheurs possèdent des opérations ‘internes’ :

• PropagateOutput() : Emet les signaux répartis vers les autres micro-noyaux et réinitialise le booléen outputPresent .

• Tick() : Lance une réaction du micro-noyau et appelle l’opérationPropagateOutput si outputPresent est devenu vrai.



La politique de déclenchement des réactions est entièrement contenue dans lesopérations EventIn et WaitReaction , et celle régissant l’émission des signauxexternes dans PropagateOutput . Plusieurs déclencheurs, proposant plusieurspolitiques ont été créés, avec cette même interface. Le choix du type dedéclencheur est fait à son instanciation, il est indépendant de son utilisation.

Nous présentons maintenant le détail de ces opérations dans le cas dudéclencheur le plus simple, pour montrer quelles sont les fonctions minimales deces opérations. Nous décrirons ensuite un déclencheur effectuant unesynchronisation par échange de messages, suivant un algorithme à vague. Cedéclencheur nous servira de référence pour évaluer les performances dudéclencheur parsemé, réalisant le modèle que nous avons présenté, et que nousexpliquerons enfin.

4.3.3.1. Le déclencheur de base

La politique de déclenchement est ici de ne lancer une réaction que quand elleest nécessaire, c’est-à-dire quand WaitReaction est invoquée. Voici le détail de ceque font les opérations :

• EventIn() : Ne fait rien.

• WaitReaction() : Invoque une première fois l’opération Tick , puisrecommence tant que l’appel à CheckNewInterrupt a détecté de nouvellesinterruptions.

• Suspend() : Suspend le thread noyau exécutant le SVP. Seule l’occurrenced’une interruption pourra provoquer son réveil.

Les signaux répartis sont émis immédiatement :

• PropagateOutput() : Demande immédiatement au gestionnaire decommunication le transfert des messages vers les autres micro-noyaux.

4.3.3.2. Le déclencheur synchronisé à vague

La synchronisation des réactions relève du problème classique du calcul paritérations réparti. Trois caractéristiques de notre configuration vont déterminernos choix pour sa réalisation :

1. Une réaction d’un SVP est un calcul à deux étapes : la première estl’exécution de la réaction elle même, et la deuxième la communication desévénements entre les SVP. Cette dernière ne doit pas avoir lieu tant que lapremière n’est pas finie sur l’ensemble des sites.

2. Le nombre de SVP interconnectés est variable. On souhaite pouvoir ajouterou retirer n’importe quel SVP au système, et ce à n’importe quel moment del’exécution.



3. Tout SVP peut être initiateur d’une réaction, et plusieurs peuvent le fairesimultanément.

La première caractéristique nous fait choisir un algorithme à vague plutôt quephasé, dans lequel tous les participants du calcul doivent diffuser à tous les autresun message d’information à chaque étape du calcul. Le nombre de messages seraitici trop important : 2.n2 par réaction. D’autre part, il serait nécessaire que chaqueSVP maintiennent sa liste des participants, ce qui serait très coûteux dans le casde notre configuration dynamique.

Les deux autres caractéristiques nous amènent à préférer l’utilisation d’unséquenceur externe, plutôt que de gérer les vagues depuis les SVP eux mêmes.Cette dernière solution consisterait à choisir un SVP maître, qui initierait lesréactions de tout le système. Les communications pourraient alors se faire soit pardiffusion, soit par adressage point-à-point à travers une liste chaînée de SVP. Lemaintien d’une telle liste est coûteux dans une configuration dynamique, donc peuadapté à notre configuration. La même remarque peut s’appliquer pour le choix duSVP maître : celui qui a été choisi à l’instant précédent peut avoir disparu, ou bienun ou plusieurs autres SVP peuvent vouloir démarrer eux-mêmes une réaction, cequi nécessite de procéder à une élection pratiquement à chaque instant dusystème.

Nous choisissons donc de créer un séquenceur externe, qui n’est pas un SVP. Ilest présent et unique sur toute la durée de vie du système. Son comportement, trèssimple, consiste à exécuter en boucle les opérations suivantes :

1. Attente d’une demande de réaction.

2. Diffusion d’un tick, commandant le passage à l’instant suivant de tout lesystème.

3. Attente de l’acquittement de ce tick par tous les SVP, signifiant qu’ils ontexécuté leur réaction.

4. Diffusion d’un sous-tick, autorisant les SVP à émettre les événements qu’ilsont produits.

5. Attente de l’acquittement de ce sous-tick.

Si plusieurs demandes de réaction arrivent au cours du même instant, lapremière reçue les satisfait toutes, les suivantes sont donc ignorées.

Le nombre de messages échangés à chaque réaction est 4.n+r, où r est lenombre de demandes de réaction à un instant.

D’autre part le séquenceur est en permanence à l’écoute des créations etterminaisons des SVP, il tient à jour leur nombre afin de savoir combiend’acquittements il doit recevoir.



Afin de répondre à ce comportement, le déclencheur synchronisé à vague desSVP réalise les opérations suivantes :

• EventIn() : Envoie au séquenceur une demande de réaction.

• WaitReaction() : Attend un tick du séquenceur, puis exécute la réactioncomme le déclencheur de base. Enfin l’acquittement du tick est envoyé auséquenceur.

• Suspend() : Teste la présence d’un tick du séquenceur; s’il y en a un, uneréaction est lancée, sinon le thread noyau exécutant le SVP est suspendu.

• PropagateOutput() : Attend le sous-tick du séquenceur, puis exécute lemême traitement que le déclencheur de base. A sa terminaison, unacquittement est envoyé au séquenceur.

On peut remarquer que dans ce mode de fonctionnement, seules deuxconditions peuvent provoquer une réaction d’un SVP : s’il le demande lui-même(séquence EventIn - WaitReaction ), ou bien s’il remarque un tick au moment de sesuspendre (méthode Suspend ). Si, dans un système réactif réparti, un SVP estbeaucoup plus lent que les autres, c’est-à-dire si ses réactions sont très espacéesdans le temps et qu’il n’est que rarement inactif, il peut imposer de longsintervalles entre les réactions à l’ensemble du système. Ceci peut provoquer unesaturation des événements en entrée, qui ne pourront plus être traités au rythmede leur occurrence. Pour éviter cette situation, un paramétrage de ce déclencheurest possible, afin qu’il devienne préemptif : l’arrivée d’un tick du séquenceur esttraitée comme une interruption matérielle, si le SVP n’est pas déjà en traind’exécuter une réaction de la gestion des tâches, le traitement en cours estinterrompu, et une réaction est lancée. Le système n’est alors plus cadencé par leplus lent de ses constituants, mais par le plus rapide. Cette situation peut aussiêtre pénalisante, les interruptions successives du SVP le plus lent pouvantl’empêcher de réaliser sa tâche. Il convient donc de choisir la configuration dudéclencheur en fonction de l’application.

4.3.3.3. Le déclencheur parsemé

Ce type de déclencheur n’exécute une réaction qu’au moment du tick globalsuivant la demande de réaction. Comme pour le déclencheur de base, on ne testepas la présence de signaux au moment du démarrage des réactions, on supposeque si WaitReaction est appelé, c’est qu’une réaction est nécessaire. Lestraitements associés à l’interface deviennent alors :

• EventIn() : Ne fait rien.

• WaitReaction() : La machine d’exécution se met en attente (attente activeen mode natif, blocage du thread noyau avec réveil programmé dans le casdes SVP) jusqu’au prochain tick global. On teste alors l’occurrence denouvelles interruptions matérielles, qui ont pu se produire pendant cetteattente, puis on exécute la réaction du micro-noyau. A la fin de cetteréaction, et des éventuelles suivantes, il faut de nouveau tester la présence



d’interruptions en attente, et les traiter au prochain tick de l’horlogeglobale.

Les signaux répartis sont émis si l’on est dansl’intervalle K, ce qui implique de vérifier d’unepart que l’on ne se trouve pas dans la période Πprécédent K, et d’autre part que l’on n’est pas dansl’intervalle dmax+Π qui suit. Dans le premier cas,on attend la fin de l’intervalle Π. La secondesituation ne devrait pas se produire, car la valeurde K a été fixée pour éviter ce cas. C’est donc une

ΠΠ

z(i) z(i)+1

Kdmax+

Décomposition d’un tick global

situation d’erreur, qui est signalée comme telle. Les messages ne sont pas envoyés,ils le seront lors de la prochaine réaction, ceci afin de respecter au moins unepartie du modèle : ils seront envoyés dans un intervalle K, tous les récepteurs lesrecevront donc au même moment (et avec la même date).

• PropagateOutput() : Lire la date locale relative au début du tick; si elle estinférieure à Π, la machine d’exécution est mise en attente; si elle estsupérieure à K+Π on génère un code d’erreur, sinon les signaux sont émis etle booléen outputPresent est réinitialisé.

4.4. Démonstration du synchronisme de l’exécutif

Nous reprenons dans ce paragraphe une application imaginée par F. Boulanger[BOUL94], mettant graphiquement en évidence les problèmes de synchronisationd’exécutions réparties. Nous montrons comment l’exécutif synchrone réparti quenous avons développé résout le problème posé.

4.4.1. Présentation de l’application “Tortues”

On souhaite représenter graphiquement le déplacement de quatre tortues, dontles positions forment initialement un carré, et qui se déplacent en suivant uneautre tortue : la première suit la deuxième, la deuxième la troisième, la troisièmela quatrième, et la quatrième la première.

Après une phase d’initialisation, pendant lesquelles les tortues secommuniquent leur référence et définissent leur position initiale, chaque tortuecalcule la distance qui la sépare de la tortue qu’elle suit. Si cette distance estsupérieure à 1, elle calcule et émet sa nouvelle position, sinon elle s’arrête.

Pour visualiser la qualité de la synchronisation, on trace graphiquement leparcours des tortues. Une synchronisation parfaite correspond à la situation danslaquelle chaque tortue lit une et une seule fois chaque position émise par sa tortuecible. Ceci ce manifeste graphiquement par le tracé suivant :



Parcours des tortues synchronisées

Nous allons réaliser ce parcours à l’aide de quatre tortues s’exécutant sur desmachines différentes.

4.4.2. Fonctionnement de la démonstration

L’application est composée de quatre exemplaires identiques de tortues, et d’unlanceur. Le lanceur a pour rôle de déterminer les positions initiales des tortues, deleur communiquer et de leur indiquer la référence de la tortue à laquelle ilsdevront donner leur position. Ces deux informations sont envoyées dans un seulmessage d’initialisation, dont la réception provoque le démarrage des tortues.Nous faisons deux hypothèses sur la configuration du système :

(H1) : Les tortues et le lanceur se trouvent dans cinq SVP différents. Cesderniers doivent localement être les tâches les plus prioritaires, ce qui enparticulier est le cas s’ils sont les seules tâches. Cette configuration nous assureque les tortues seront immédiatement ordonnancées dès qu’elles le pourront.Idéalement, chaque SVP devrait s’exécuter sur une machine différente, mais pourdes raisons pratiques (disponibilité des machines...) il peut être nécessaire d’enexécuter plusieurs sur la même. On dispose alors d’une synchronisation parfaitedes horloges (Π=0), mais la notion de simultanéité perd un peu de son sens.

(H2) : Le code des tortues étant très simple, les machines sur lesquels elless’exécutent doivent toutes permettre l’exécution du code compris entre deuxinvocations du micro-noyau en au plus (dmax+Π)/N, où N est le nombre de tortuess’exécutant sur la même machine. Ainsi lorsqu’une tortue reprend la main, on estsûr qu’elle aura le temps d’exécuter son traitement et de demander une réactiondu micro-noyau synchrone avant le tick global suivant son activation.



Tous les messages d’initialisation sont communiqués simultanément (en uneseule émission de message) à l’ensemble des tortues. L’exécutif réparti garanti queles quatre micro-noyaux recevront simultanément ces messages, à une date globaleque nous appellerons t0. Les tortues étant immédiatement ordonnancées (hyp.H1), leur démarrage est lui aussi simultané, à la date globale t0.

Chaque tortue émet alors sa position à la tortue qui la suit, informationeffectivement émise par le micro-noyau à la réaction de date t0+1 (hyp. H2). Puisla tortue interroge le micro-noyau pour savoir si un message en provenance de latortue qu’elle suit est arrivé. Cette interrogation est non bloquante, c’est à direqu’il n’y a pas de délai d’attente. Cette demande provoque une réaction du micro-noyau, à la date t0+2 (hyp. H2). A cette date toutes les positions initiales ont étéreçues par les micro-noyaux (propriété de l’exécutif). Chaque tortue récupère doncimmédiatement la position initiale de la tortue qu’elle suit. Elle calcule alors sanouvelle position, et l’émet à la date t0+3 (hyp. H2). La tortue exécute alors enboucle :

• lecture, si disponible de la position de la tortue suivie.

• calcul de la nouvelle position, et émission de celle-ci.

Si la position de la tortue n’est pas arrivée, c’est que les tortues sontdésynchronisées; dans ce cas la tortue considère la dernière position qu’elle a reçue(si elle en a reçu) comme cible, et émet tout de même une nouvelle position. Cessituations d’erreur vont provoquer une modification du parcours des tortues, quiapparaîtra sur le tracé.

Voici le graphe temporel représentant l’historique des messages que noussouhaitons obtenir :

lanceur

tortue 1

tortue 2

tortue 3

tortue 4

t0−1 t0 t0+1 t0+2 t0+3 t0+4 t0+5

Graphe temporel des messages échangés

4.4.3. Résultats

Nous implantons cet exemple afin d’une part de vérifier le bon fonctionnementde notre synchronisation, et d’autre part d’évaluer ses performances par rapport àune synchronisation classique par échanges de messages.

Les résultats de l’exécution sont récupérés de la façon suivante :



Les quatre tortues sont lancées en leur donnant en paramètre un nom. Ellescréent un fichier à ce nom dans lequel elles écrivent à chaque étape de leurparcours leur position. A chaque fois qu’une tortue ne trouve pas la nouvelleposition de sa cible, ce qui correspond à une erreur de synchronisation, elleincrémente un compteur. En fin d’exécution chaque tortue affiche le nombred’erreurs qu’elle a détectées, et le temps écoulé entre l’émission de sa positioninitiale et l’instant ou elle a rejoint sa cible. Le nombre d’erreurs doit être égal àzéro pour que la synchronisation soit valide, et le temps d’exécution le plus courtpossible pour qu’elle soit intéressante. Le tracé du parcours des tortues peut êtreobtenu en chargeant les quatre fichiers de positions des tortues dans un logiciel deprésentation graphique de données.

4.4.3.1. Sur un exécutif non synchronisé

Nous utilisons dans un premier temps le déclencheur de base, afin de constaterles effets de la désynchronisation. Les hypothèses H1 et H2 sont toujours vérifiées.

Le code des tortues doit être adapté pour pouvoir fonctionner sanssynchronisation. En effet la phase d’initialisation, dans la version la plus simpledes tortues, requiert que les différents messages soient reçus séquentiellement, àdes instants différents. Ceci n’est pas garanti quand l’exécutif n’est passynchronisé : la position initiale d’une tortue, en provenance du lanceur, peut êtrereçue dans le même instant qu’une ou plusieurs positions de la tortue cible, si cettedernière s’exécute plus rapidement. Il devient alors nécessaire de parcourir ungroupe de messages pour retrouver l’information désirée. Il faut aussi décider dutraitement à effectuer sur les messages reçus non-attendus : les mettre en attenteafin de les traiter à l’instant suivant, ou les abandonner. La première solutionpermettrait de diminuer le nombre d’erreurs de synchronisation, en récupérant lesmessages en avance. Toutefois il resterait des erreurs à cause des messages enretard. Notre but n’étant pas de mettre une partie de la synchronisation dans lecode de l’application, nous avons opté pour la deuxième solution, qui perd lesmessages arrivés s’ils ne sont pas attendus.

Il arrive fréquemment que la position de la tortue suivie ne soit pas disponibleau moment où elle est demandée, car l’émission n’est pas synchronisée avec laréception. Dans ces situations, la tortue se rapproche plus directement de cellequ’elle suit, en décentrant sa trajectoire, et, par effet de cascade, de toutes lesautres. Ceci produit des trajectoires irrégulières et asymétriques, qui convergentailleurs qu’au centre du carré formé par les positions initiales (exemple (a) et (b)).L’exécutif n’offrant aucune garantie, il peut même arriver que certaines tortuesrestent bloquées, parce qu’elles mettent beaucoup plus de temps à réagir que lesautres. C’est le cas de l’exemple (c).



Exemples (a), (b) et (c) de graphes produits par une désynchronisation

Performances

Configurations Sur 1 site Sur 2 sites Sur 5 sitesDurées 12 à 14 sec 6,2 à 6,8 sec ??

Les durées des traitements sont très variables, et n’ont que peu d’intérêt detoute façon puisque le résultat n’est pas valide.

4.4.3.2. Sur un exécutif synchronisé par déclencheur à vague

Bien qu’il soit relativement simple, ce déclencheur a été le plus long à réaliser :il nécessite tout de même la définition d’un dialogue entre les SVP et leséquenceur, donc d’une gestion de communications et d’un mécanisme depréemption du type de celui des interruptions matérielles.

Nous utilisons la version non préemptive de ce déclencheur, car si oninterrompt le traitement d’une tortue, elle ne fournit pas sa position à cet instant,ce qui produit une erreur chez le destinataire de cette information.

Le résultat de la synchronisation est valide (0 erreur), et aucune adaptationn’est à faire suivant la configuration.

Performances

Configurations Sur 1 site Sur 2 sites Sur 5 sitesDurées 18 à 19 sec 17,5 à 18,5 sec 13,5 à 13,5 sec

Les performances sont correctes, mais l’exécution monopolise une quantitéimportante de temps CPU et de bande passante sur le réseau. D’autre part nouspouvons remarquer que le coût de la synchronisation fait perdre en grande partiele gain de la parallèlisation : le temps d’exécution ne diminue presque pas entre laversion monosite et celle la plus répartie.



4.4.3.3. Sur un exécutif synchronisé par déclencheur clairsemé

Les valeurs utilisées pour le calcul de la période du déclencheur parsemédoivent prendre en compte le fait que notre micro-noyau (SVP) s’exécute au-dessusd’un autre noyau (CHORUS). Ceci est important pour déterminer les valeurs dedmax et K. La valeur de dmax doit inclure le temps de communication des messagessur le réseau, mais aussi tout l’overhead de l’interface noyau et l’exécution dunoyau lui-même. K doit prendre en compte le fait que d’autres tâches s’exécutentsur la machine : le noyau, qui possède des tâches de très forte priorité, mais aussiles autres tortues, dans les configurations où elles ne sont pas toutes isolées.

Configuration monosite (486/50) : ΠΠ = 0 / dmax = 1ms / K = 50ms

Le problème de la synchronisation des horloges ne se pose pas ici, puisqu’il n’yen a qu’une. La valeur de Π est donc 0.

Le délai des communications n’est pas nul, car c’est un thread spécialisé quireçoit les messages et les transmet à la gestion des tâches. Il faut donc prendre encompte l’ordonnancement de ce thread dans les communications. Nous fixons lavaleur de dmax à 1ms.

La valeur de K est calculée à partir de la durée maximum de 5 réactions. Desmesures nous ont permis de déterminer une valeur maximum de 10ms pour ladurée des réactions. La durée maximum de 5 réactions est donc Rmax = 50ms..Cette valeur n’est pas garantie dans la version actuelle, car d’une part notresystème s’exécute au dessus du noyau CHORUS, qui n’offre pas de garantietemporelle, et d’autre part nous n’avons de moyen de déterminer formellementcette valeur. Les réactions débutant en début de période gg, il faut, pour que lesystème fonctionne correctement, que leur exécution soit terminée à la fin del’intervalle K. Elles disposent donc de Π+K pour s’exécuter. Nous pouvons fixer lavaleur de K :

K = Rmax-Π = 50.

Configurations multisite : ΠΠ = 4~8ms / dmax = 8ms / K = N.9ms

La version actuelle de la gestion des communications fonctionne sur Ethernet,qui n’est pas déterministe. Ceci est une faiblesse du prototype, qui devrait se basersur des communications au délai borné. Toutefois des mesures nous ont permisd’évaluer un délai maximum exceptionnellement dépassé. Nous utiliserons cettevaleur, pour fixer dmax : 8ms. Un portage des communications sur FDDI permettrad’abaisser cette variable à une valeur sûre de l’ordre de 3ms.

Nous avons réalisé un protocole de synchronisation assurant une précision de4ms entre un site maître, servant d’horloge de référence, et les autres sites. Dansune configuration à deux sites, si l’un des deux est le site maître, la valeur de Π est4ms. Dans une configuration impliquant plus de machines, l’écart maximum entredeux horloges est doublé, car il faut considérer la situation où deux sites ont lemaximum de décalage avec le maître, l’un étant en avance, l’autre en retard. La



valeur de Π est alors 8ms. Cette synchronisation n’offre pas des performancessatisfaisantes pour deux raisons : les échanges de messages se font sur Ethernet,qui ne permet pas une estimation d’une horloge distante avec une précisionsupérieure à 2ms (à cause de la durée et l’indéterminisme des communications); lerésultat actuel est obtenu avec un noyau CHORUS ayant une période d’interruptionhorloge de 8ms. Or il n’est pas possible d’avoir une précision inférieure à la moitiéde la période. Nous utilisons cette configuration du noyau parce qu’une fréquencesupérieure provoque la perte d’une interruption horloge de temps en temps, ce quise manifeste par des écarts importants entre les sites, résultat inverse de celui quenous souhaitons. D’autre part les performances de notre gestion des tâches sontcompromises si le noyau sous-jacent l’interrompt trop souvent.

La valeur de K est calculée à partir du nombre de SVP co-résidant sur lamachine. Dans la configuration à deux sites, un site exécute trois zonessynchrones, l’autre deux. On a donc Rmax=30ms.

K = Rmax - Π = 30 - 4 = 26ms

Dans la configuration à 5 sites, il n’y a qu’une zone synchrone par site,Rmax=10ms.

K = Rmax - Π = 10 - 8 = 2ms

Une fois ces trois valeurs déterminées, le système fonctionne correctement, dela même façon qu’il fonctionnerait de façon synchrone sur un seul site : lesmessages communiquant les positions des tortues sont toujours présents lorsqu’ilssont demandés, les tortues s’exécutent en parallèle au même rythme.

Performances

Configurations Sur 1 site Sur 2 sites Sur 5 sitesDurées 23,3 sec 19,2 sec 11,9 sec

Ces résultats, vérifiés par l’expérimentation, peuvent être calculés a priori.Nous savons que les tortues, si elles sont synchronisées, convergent au bout de 229itérations. Il y a donc 229 émissions et 228 réceptions de positions. La durée D,déterministe, de leur parcours est donnée par la formule :

D = (2Π + dmax + K) * (229 + 228)

On remarque que ce déclencheur est de plus en plus performant au fur et àmesure que la répartition augmente. Ceci s’explique par le fait que l’on tire profitdu parallélisme des exécutions sans payer le coût de la synchronisation. Lorsqueplusieurs tortues se trouvent sur le même site, la performance est moins bonneque le déclencheur à vague, car la multiplication des durées maximum desréactions augmente fortement K.



Ce déclencheur monopolise beaucoup moins de ressources que le précédent : iln’y a pas de messages de synchronisation échangés, ce qui libère le réseau, et lespériodes étant calculées sur des temps d’exécution au pire, elles laissent en généraldu temps CPU aux autres tâches moins prioritaires du système. Par contre sonutilisation est un peu moins facile, il faut définir les paramètres de l’exécutif enfonction de la configuration du système et de l’application.

Le prototype repose sur deux outils système : le protocole de communication etla synchronisation des horloges. La version actuelle de ces deux éléments n’offrepas des performances satisfaisantes. Malgré cela, le déclencheur parsemé offre untemps d’exécution comparable au déclencheur à vague, et même meilleur danscertaines configurations. Leur amélioration permettrait un gain de tempsimportant qui montrerait de façon plus évidente encore l’intérêt de notre approche.

4.5. Conclusion

Nous avons montré comment rendre déterministe l’exécution d’un réseaud’objets réactifs réparti, en utilisant un modèle sémantique différent de celui de laprogrammation synchrone : le modèle synchrone faible ne suppose pas unepropagation instantanée des signaux entre les objets réactifs.

Nous avons appliqué ce modèle à l’exécution de plusieurs instances de notregestion synchrone des tâches communiquant par messages asynchrones. L’exécutifainsi réalisé offre au niveau applicatif une notion de temps logique facilitant lasynchronisation des applications réparties.

Les applications temps-réel nécessitent des garanties temporelles sur leurexécution. Nous avons donc réalisé une implémentation du temps logique ancréedans le temps physique, qui ne nécessite pas d’échanges de messages entre leszones synchronisées. Les performances de cette réalisation sont proches de cellesobtenues avec un exécutif ne fournissant qu’un temps purement logique. Dans sonétat actuel, le prototype de l’exécutif s’appuie sur des composants indéterministes :le réseau (Ethernet) et le système sous-jacent (CHORUS). Pour cette raison, iln’offre pas toutes les garanties que l’on peut en espérer. L’utilisation d’un réseauFDDI permettrait de s’assurer une valeur maximum sur la durée descommunications.

Le temps logique que nous avons créé est utilisable depuis n’importe quelmodèle de programmation, mais il serait particulièrement utile pour l’exécutiond’objets réactifs. En effet ces objets disposent explicitement de la notion d’instantdans leur sémantique. Notre plate-forme est donc idéale pour supporter uneapplication temps-réel répartie contrôlée par des objets réactifs. Elle ne disposepas actuellement d’interface particulière pour l’exécution de ce type d’objets, qui enferait une machine d’exécution synchrone native répartie. Réaliser cette interfaceserait une amélioration majeure.


Gestion de processus d'un micro-noyau de système d'exploitation répartie avec garantie de service

Conclusion et perspectives

Nous avons montré dans cette thèse l’intérêt de l’utilisation de l’approchesynchrone dans la réalisation des systèmes d’exploitation dits “temps-réel”, quidoivent garantir aux applications les propriétés qu’elles requièrent sur leursexécutions. Pour cela notre étude a porté sur un prototypage d’une gestionsynchrone des tâches.

Gestion synchrone des tâches

Nous avons présenté une réalisation de la gestion des tâches d’un noyau desystème d’exploitation par la composition d’objets réactifs programmés en langagesynchrone. Ce travail a nécessité l’étude d’une gestion des tâches existante, celledu système CHORUS, et son découpage en unités fonctionnelles. Chacune a alors puêtre implantée dans un objet réactif.

Nous avons ensuite défini la machine d’exécution minimale nécessaire à cesobjets. Nous en avons proposé une implantation réelle au-dessus du noyauCHORUS, sous forme d’une gestion de threads utilisateur.

Ce travail a permis d’obtenir un système dont :

• on possède une description formelle;

• on peut prouver des comportements, que l’on sait être déterministes;

• la structure est modulaire, à deux niveaux : le système est divisé en objetschargés de fonctions précises, qui sont eux-même divisés en un code réactifet un code transformationnel. Ce découpage facilite la conception, les tests,et l’évolution (modifications d’une politique, ajout d’une fonction...) dusystème.

L’implantation réelle a permis de montrer la faisabilité d’un tel système.Toutefois les performances temporelles se sont révélées décevantes, mais uneanalyse des causes a montré qu’elles n’étaient pas inhérentes à l’approche. Unemodification des librairies d’exécution des objets réactifs, dont on a donné lescaractéristiques, permettrait de remédier à ce problème.

Conclusion et perspectives 135


Synchronisation répartie

Nous nous sommes ensuite intéressés à l’exécution répartie d’objets réactifs. Lasynchronisation de l’exécutif réparti offre un modèle d’exécution permettant desimplifier la réalisation d’applications réparties. Ces dernières peuvent utiliser lasynchronisation native du système, ce qui leur évite ce travail au niveau applicatif.L’approche synchrone a permis de rendre cet exécutif déterministe, ce qui en faitun bon support pour la réalisation d’applications temps-réel.

Nous avons montré différents modes d’exécution d’objets réactifs répartis,allant de la concurrence sans contrôle à la synchronisation couplée à un tempsphysique. Nous avons proposé une réalisation de la synchronisation basée sur lemodèle sémantique du synchronisme faible COREA, en utilisant unesynchronisation reposant sur la détermination d’un temps global. Cette méthodeévite de charger le réseau et le processeur avec un protocole coûteux, tout endonnant des bons résultats.

Ce travail nous a amené à concevoir un déclencheur de réaction, indépendantde la machine d’exécution, qui décide du démarrage des réactions du système, àpartir d’informations élémentaires sur l’état du système (occurrence d’unévénement quelconque), suivant une politique qui lui est propre.

Nous avons enfin montré, à travers un exemple, comment utiliser les propriétésde synchronisme de l’exécutif ainsi créé pour réaliser des applicationssynchronisées.

Perspectives

Le premier prolongement de cette étude est l’optimisation de l’environnementd’exécution des objets synchrones, qui a jusqu’ici été développé pour desapplications synchrones ‘utilisateur’, jamais à un niveau si bas dans le système.Avec ce nouveau type d’utilisation du synchronisme, la nécessité d’une structured’exécution plus légère et performante est apparue. La description desmodifications à effectuer est donnée au chapitre 3.

Nous avons mentionné en fin du premier chapitre la possibilité d’utiliser notresystème comme machine d’exécution synchrone native. Nous n’avons pasdéveloppé cette possibilité, par manque de temps, mais elle serait trèsintéressante : elle permettrait de réduire le coût de l’interface actuelle en faisantcorrespondre directement certains signaux d’entrées du système à des signauxd’interfaces des objets réactifs. Ces derniers seraient alors un type de tâcheparticulier, qui n’utiliserait qu’une partie de l’interface de la gestion des tâches :un objet réactif est bloqué en attente d’événements (fonction Sleep/Awake) à sonentrée, éventuellement avec une échéance; il est stimulé par l’occurrence d’un desévénements attendus, ou de l’échéance; il exécute alors une réaction, produit desévénements de sortie, puis se remet en attente de nouveaux événements d’entrée.Un événement de sortie, s’il n’est pas traité immédiatement par du codeasynchrone, est destiné soit à la gestion des tâches, soit à un objet réactif. Dans cedernier cas, le destinataire est réveillé (occurrence du signal Awake de la gestiondes tâches). Après une réaction, la gestion des tâches est toujours activée, puisque

136 Conclusion et perspectives


l’objet réactif s’est bloqué, elle traite alors les événements qui lui sont destinés etdécide de la nouvelle tâche à activer, éventuellement un autre objet réactif quivient d’être réveillé.

Le système actuel est un prototype. Pour qu’il constitue le système avec garantide service présenté au chapitre 1, quatre étapes sont nécessaires :

1. Améliorer les performances, nous en avons parlé;

2. Intégrer les autres outils de la gestion de la qualité de service (politiqued’ordonnancement, supervision,...) présentés en 1.2; cette phase peut sefaire au niveau utilisateur, ce qui facilite le développement.

3. Compléter le noyau pour qu’il contienne toutes les fonctions d’un noyauminimum (principalement gestion de la mémoire et des communications).

4. Implanter le noyau ainsi obtenu en tant que noyau natif du systèmed’exploitation

Conclusion et perspectives 137


Bibliographie

[90295] OSI DM & ODP, “X.902 : Basic Reference Model of Open DistributedProcessing - Part 2 : Descriptive Model”. ISO/IEC JTC1/SC21, 1995

[90395] OSI DM & ODP, “X.903 : Basic Reference Model of Open DistributedProcessing - Part 3 : Prescriptive Model”. ISO/IEC JTC1/SC21, 1995

[ADE93] M. Adelantado, F. Boniol, R. Porche, “Un modèle Synchrone etDéterministe pour le Temps-Réel”. 5ème Rencontres sur le Parallèlisme,Brest, France, mai 1993

[ARC95] J.-B. Stefani, F. Dangtran, L.Hazard, V. Perebaskine, F. Horn, P.Auzimour, “A Real-Time DPE on top of CHORUS”. Note Technique CNETNT/PAA/TSA/TLR/4179, janvier 1995

[BAN80] J.S. Banino, A. Caristan, M. Guillemont, G. Morisset, H. Zimmermann,“CHORUS : an Architecture for Distributed Systems”. Research ReportINRIA, Rocquencourt, France, novembre 1980

[BEJ96] J. Bejjani, “Supervision de la Qualité de Service sur un Systèmed’Exploitation Réparti Temps-Réel”. Thèse de l’ENST à paraître mi 1996

[BEN91] A. Benveniste, G. Berry, “The Synchronous Approach to reactive andreal-time systems”. IEEE, septembre 1991

[BER83] G. Berry, S. Moisan, J-P. Rigault, “ESTEREL : Toward a synchronous andsemantically sound high level language for real time applications”. Proc.IEEE Real Time Symp., 1983

[BER87] G. Berry, P. Couronné, G. Gonthier, “Programmation synchrone dessystèmes réactifs : le langage ESTEREL”. T.S.I. n°4, 1987

[BER93] R. Bernhard, “Description du premier prototype de la machine d’exécutionESTEREL”. Document INRIA-Cerics, janvier 93

Bibliographie 139


[BEY92] G. Berry, G. Gonthier, “The ESTEREL synchronous language : Design,Semantic, Implementation”. Journal of Science Of ComputerProgramming, Vol 19, Num 2., pp87-152, 1992

[BOU91] F. Boussinot, R. de Simone, “The ESTEREL language”. Proceedings of theIEEE, septembre 1991

[BOU94] F. Boulanger, “Intégration de Modules Synchrones dans laProgammation par Objets”. Thèse de Doctorat de l’Université d’Orsay,décembre 1994

[CAS94] C. Castellucia, I. Chriment, W. Dabbous, C. Diot, C. Huitema, E. Siegel,R. de Simone, “Tailored Protocol Developpement Using ESTEREL”.Rapport de recherche INRIA n°2374, octobre 1994

[CCD94] C. Castelluccia, I. Chriment, W. Dabbous ,C. Diot, C. Huitema, E. Siegel,R. de Simone, “Tailored Protocol Development Using ESTEREL”. Rapportde recherche n°2374, octobre 1994

[CHE88] D. Cheriton, “The V Distributed System”. Comm. of the ACM, vol. 31, no.3, pp 314-333, mars 1988

[CHO92] Chorus Systèmes, “CHORUS kernel & MIX, Implementation Guide”. 1992

[CLA91] E.M. Clarke, D.E. Long, K.L. McMillan, “A Language for CompositionalSpecification and Verification of Finite State Hardware Controllers”.Proceedings of the IEEE, septembre 1991

[CRE95] P. Cregut, “Langage de descrption des procédures de taxations pour lespubliphones”. Note technique CNET NT/LAA/EIA/57, mars 1995

[FAU94] P. Fauvel, F. Horn, “Présentation d’ODP”. Note technique CNETNT/PAA/TSA/TLR/3837, mai 1994

[FER90] D. Ferrari, “Client requirements for real time communication services”.Research Reports ICSI TR-90-007, Berkeley, California, USA, mars 1990

[GIR94] A. Girault, “Sur la répartition de programmes synchrones”, Thèse dedoctorat de l’Institut National Polytechnique de Grenoble, janvier 1994

[GOP89] P. Gopinath, K. Schwan, “CHAOS : Why One Cannot Have Only AnOperating System for Real Time Applications”. ACM-OSR, juin 1989

[GUE91] P. le Guernic, T. Gautier, M. le Borgne, C. le Maire, “Programming Real-Time Applications with SIGNAL”. Proceedings of the IEEE, septembre1991

140 Bibliographie


[HAL91] N. Halbwachs, P. Caspi, P. Raymond, D. Pilaud, “The Synchronous DataFlow Programming Language LUSTRE”. Proceedings of the IEEE,septembre 1991

[HAR85] D. Harel, A. Pnüeli, “On the development of Reactive Systems”. K. Apt,Ed., Logics and Models of Concurrent Systems, NATO ASI series,Springer, New York, 1985

[HAR87] D. Harel, “Statecharts : A visual formalism for complex systems”. Scienceof Computer Programming, vol. 8, no. 3, pp 231-274, juin 1987

[HAZ93] L. Hazard, R. Bernhard, F. Horn, J.-B. Stefani, “Implementation of asynchronous execution machine on CHORUS micro-kernel”. Proc. IEEERTSS’93, Durban USA, décembre 1993

[HHS93] L. Hazard, F. Horn, J.-B. Stefani, “Somme computational andengineering aspects of streams”. CNET, février 1993

[JAH86] F. Jahanian, A. Mok, “Safety Analysis of Timing Properties in Real-TimeSystems”. IEEE Transactions on Software Engineering, septembre 1986

[KOP89] H. Kopetz, A.Damm, C. Koza, M. Mulazzani, W. Schwabl, C. Senft, R.Zainlinger “Distributed Fault-Tolerant Real-Time Systems : The MARSApproach”. IEEE Micro, février 1989

[KOP92] H. Kopetz, “Sparse time versus Dense time in distributed real timesystems”. IEEE Symp. On Distributed Systems, 1992

[LAM78] L. Lamport, “Time, Clocks and the ordering of events in a DistributedSystem”. Comm ACM, vol 21, n°7, juillet 1978

[LAM84] L. Lamport, “Using Time instead of Timeout for Fault-TolerantDistributed Systems”. Comm ACM Trans. on Programming Languagesand Systems, vol 6, n°2, avril 1984

[LEB89] V. Lecompte, F. Boussinot, “Une application de la programmationsynchrone : Le modem du minitel en ESTEREL”. Rapport CNRS-C2A, mai1989

[LEC89] V. Lecompte, “Vérification automatique de programmes ESTEREL”. Thèsede doctorat de l’université Paris 7, 1989.

[LEV89] S.T. Levi, S.K. Tripathi, S.D. Carson, A.K. Agrawala, “The MARUTI Hardreal Time Operating System”. ACM-OSR, juin 1989

[LMV87] V. Lecompte, E. Madelaine, D. Vergamini., “Auto : un système devérification de processus parallèle et communicants”. rapport INRIAn°83, 1987

Bibliographie 141


[MCJ88] P.R. McJones, G.F. swart, “Evolving the Unix System Interface toSupport Multithreaded Programs”. TR21, DEC Systems ResearchCenter, Poalo Alto, septembre 1988

[MER89] H. Tokuda, C.W. Mercer, Y. Ishikawa, T.E. Marchok, “Priority Inversionsin Real-Time Communication”. Proc. of the 10th IEEE Real-TimeSystems Symp., décembre 1989

[MIL83] R. Milner, “Calculi for synchrony and asynchrony”. Theoretical ComputerScience, 25(3), 1983

[MRS95] H. Marchand, E. Rutten, M. Samaan, “Specifying and verifying atransformer station in Signal and SignalGTi”. Publication interne IRISAn°916, mars 1995

[MUL87] S.J. Mullender, “The Amoeba Distributed Operating system : SelectedParpaers 1984-1987”. CWI Tract No. 41, Amsterdam, Netherlands, 1987

[NAK90] H. Tokuda, T. Nakajima, P. Rao, “Real Time Mach : Towards aPredictable Real-Time System”. Proceedings of the USENIX MachWorkshop, octobre 1990

[NIR90] V.M. Nirkhe, S.K. Tripathi, A.K. Agrawala, “Language Support for theMARUTI Real-Time Systems”. Proceedings of 11th IEEE Real-TimeSystem Symposium, 1990

[POW91] D. Powell, “DELTA-4 : a Generic Architecture for Dependable DistributedComputing”. RR Esprit, 1991

[RAA88] M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont,F. Herrmann, C. Kaiser, S. Langlois, P. Lànard, and W. Neuhauser.“CHORUS distributed operating systems”. Computing Systems 1(4), pp305-367, 1988.

[RAJ92] S.C.V. Raju, R. Rajkumar, F. Jahanian, “Monitoring Timing Constraintsin Distributed Real Time Systems”. Proceedings of 13th IEEE Real-TimeSystem Symposium, 1992

[RAS86] R. Rashid, “Threads of a new system”. Unix Review, août 1986

[ROB95] P. Robin, “Implementation of a Split Level Scheduling in the CHORUS

microkernel”. Rapport interne projet SUMO, CNET et Université deLancaster, mai 1995.

[SAV90] S. Savage, H. Tokuda, “Real-Time Mach : Exporting time for the user”.Research Report of Carnegie Mellon university, 1990

142 Bibliographie


[STA89] J. Stankovic, K. Ramamrithan, “The SPRING Kernel : A New Paradigmfor Real-Time Operating Systems”. ACM-OSR, juin 1989 / IEEESoftware, mai 1991

[STE92] J.-B. Stefani, L. Hazard, F. Horn, “Computational model for distributedmultimedia applications based on synchronous programming language”.Computer communications, mars 1992

[STE93] J.-B. Stefani, “Some Computational Aspects of QoS in ANSA”. ISAtechnical report, janvier 1993

[TOK89] H. Tokuda, C.W. Mercer, “ARTS : A Distributed Real-Time Kernel”. ACM-OSR, juin 1989

[TOK90] H. Tokuda, C.W. Mercer, “The ARTS Real-Time Object Model”.Proceedings of 11th IEEE Real-Time System Symposium, 1990

[TOK91] H. Tokuda, T. Nakajima, “Evaluation of RT Synchronization in RTMach”. Proc of the USENIX Mach Symp, novembre 91

[VER92] D. Vergamini, “AUTO/MAUTO User Manual, version 2-3”. INRIACERICS, janvier 92

Bibliographie 143


Annexes

1 CHORUS

CHORUS a originellement été un projet INRIA de 1979 à 1986 [BAN80], il estactuellement développé par Chorus systèmes. C’est un micro noyau, au-dessusduquel ont été développés différents sous-systèmes, dont un environnement UNIXnommé MiX.

Le micro noyau CHORUS gère, au plus bas niveau, les ressources physiques dusite sur lequel il s’exécute. Il est composé de quatre composants principaux :

1. le superviseur (supervisor), qui aiguille les interruptions, trappes etexceptions que le matériel produit;

2. l’exécutif temps-réel (real-time executive), qui contrôle l’allocation duprocesseur, fournit des mécanismes de synchronisation et possède unordonnancement préemptif à priorité;

3. le gestionnaire de mémoire virtuelle (virtual memory manager) qui manipulela mémoire physique en fournissant une mémoire virtuelle; sur chaque site,on distingue deux espaces d’adressage : l’espace système et l’espaceutilisateur;

4. le gestionnaire de communication inter-tâches (inter-process communication(IPC) manager) qui permet des communications synchrones (ipcCall() quicorrespond à un appel bloquant, ipcReply() pour le débloquer) etasynchrones (ipcSend() , ipcReceive() ) en assurant une transparence à lalocalisation.

Le superviseur et une partie du gestionnaire de mémoire virtuelle sontfortement dépendants de la machine sur laquelle ils s’exécutent, les autrescomposants sont portables. Le micro noyau manipule des entités que nous allonsmaintenant définir.

Annexes 145


Groupes deportes

porte

site site

Message

acteurthreads

Réseau

Les entités CHORUS

Un Identificateur Unique (Unique Identifier, UI) est un nom permettant dedésigner de manière unique sur le réseau CHORUS une entité. Le noyau garantitcette unicité, et s’assure qu’un UI ne sera pas réutilisé. Un UI est constitué de 128bits, qui incluent la référence du site sur lequel il a été créé, ce qui est unepremière piste pour localiser l’entité qu’il désigne.

Un Acteur (Actor) est l’unité d’allocation de ressources sur un site. Il définit unespace d’adressage protégé qui supporte l’exécution d’un ou plusieurs threads quipartagent toutes les ressources de leur acteur. Chorus définit trois typesd’acteurs : les acteurs utilisateurs, systèmes et superviseurs. Ils se différencientpar leur droit à exécuter certaines opérations sensibles (modifications deprotections, masquages d’événements, opérations sur la mémoire...) et certainesinstructions processeur privilégiées (E/S de bas niveau par exemple). Les acteursutilisateurs n’ont droit ni à l’un, ni à l’autre, les acteurs systèmes peuvent exécuterles opérations sensibles, et les acteurs superviseurs peuvent tout faire. Cesderniers s’exécutent dans l’espace d’adressage système. Plusieurs acteurs peuvents’exécuter sur le même site, les acteurs utilisateurs et systèmes ont chacun leurespace d’adressage, les acteurs superviseurs partagent le même espace d’adressagesystème. Un acteur ne peut pas être distribué, la totalité de ses ressources se situesur le même site. Un acteur est désigné par une capacité, construite à partir del’UI de sa porte de communication par défaut et d’une clef. La connaissance decette capacité donne tous les pouvoirs sur l’acteur. Au départ, seul le créateur del’acteur connaît cette capacité, mais il peut la transmettre. A l’intérieur d’unacteur, les ressources sont désignées par des identificateurs locaux, qui n’ontaucun sens en dehors de leur acteur.

Un thread est l’unité d’exécution séquentielle. Il est attaché à un acteur, il enpartage les ressources avec les autres threads. Il est caractérisé par un contextedécrivant l’état d’une exécution. Les threads d’un même acteur s’exécutent defaçon concurrente, au même titre que des threads situés dans différents acteursd’un site; si le site dispose de plusieurs processeurs ils peuvent s’exécuter enparallèle. La politique d’ordonnancement de base du noyau est préemptive àpriorité, mais il est possible de définir différentes classes de threads pour affiner le

146 Annexes


comportement de cette politique, en y ajoutant par exemple une gestion du tempspartagé (time-slicing).

Les threads d’un même acteur peuvent communiquer par mémoire partagée, àl’aide de mécanismes de synchronisation, mais des threads situés dans deuxacteurs différents, qu’ils soient sur le même site ou non, s’envoient des messagesgrâce au mécanisme d’IPC de CHORUS. Un message est un ensemble d’octetsrecopié d’un espace d’adressage à un autre. Si ces deux espaces d’adressage sontsur le même site, des optimisations du type “copy-on-write” sont possibles. L’unitéd’adressage d’un message est la porte ou le groupe de portes. Une porte (ou ungroupe de portes) est accédé par son UI; elle contient une file d’attente pourstocker les messages reçus non lus. Une porte est attachée à un acteur au momentde sa création, qui peut avoir lieu dynamiquement, à la demande d’un thread del’acteur propriétaire de la porte ou non. Seuls les thread de l’acteur détenteur de laporte peuvent lire les messages y arrivant. Une porte peut être migrée d’un acteurà un autre, ce qui implique la migration des messages en attente qu’elle contient.Des portes peuvent être liées dans un groupe de portes. Ce groupe devient uneabstraction (identifiée par un UI) à laquelle on peut adresser des messages.Différents modes d’adressage sont alors disponibles : envoi à toutes les portes dugroupe, ou à une seule porte du groupe, cette porte pouvant être soit quelconque,soit située sur un site défini, soit située sur n’importe quel site sauf un, lui aussidéfini dans l’adressage.

L’unité de travail de la mémoire virtuelle est le segment, qui est désigné parune capacité. Un segment est généralement construit comme un bloc de mémoiresecondaire; il peut avoir une taille variable. Les segments sont gérés par desacteurs systèmes nommés mappers.

L’espace d’adressage d’un acteur est divisé en régions. Une région contient uneportion de segment mappée à une adresse virtuelle avec un ensemble de droits.Les threads de l’acteur accèdent à une donnée d’un segment à travers une adressevirtuelle dans une région, avec contrôle d’accès; ils ont tous les droit (création,écriture, lecture, destruction) sur les régions appartenant aux acteurs dont ilspossèdent la capacité.

Annexes 147


2 Le langage synchrone ESTEREL

2.1 Les entrées d’un programme ESTEREL

Les entrées d’un programme ESTEREL peuvent être de deux types :

• Les informations continues, qui sont des paramètres de l’environnement(e.g. une température). Ces informations sont mesurées par des capteurs(e.g. un thermomètre), ‘sensor’ dans la syntaxe ESTEREL. Il faut bien noterque c’est l’information qui est continue, la mesure est elle ponctuelle, à lademande du système.

• Les signaux, qui informent le système qu’une situation prédéterminée s’estproduite dans l’environnement (e.g. le dépassement d’une températuredonnée). Un signal possède un statut (présent / absent) qui peut être testé.Lors de son émission, une valeur peut éventuellement lui être affectée, ilest qualifié de valué, tout processus a alors la possibilité de lire cette valeurdans l’instant de son émission. Un signal peut ne pas posséder de valeur, ilest alors qualifié de pur. Lorsque plusieurs occurrences d’un signal valué seproduisent dans la même réaction, le programmeur doit fournir unefonction permettant de combiner les valeurs des occurrences. Par exemplesi un signal de type entier est émis deux fois avec les valeurs 2 et 5, leprogrammeur peut demander de combiner ces valeurs avec une fonctiond’addition, la valeur du signal sera alors 7.

Le type de la valeur des signaux et capteurs est déterminé lors de leurdéclaration.

La communication des signaux à l’intérieur d’un programme ESTEREL (dans lalimite de sa portée syntaxique) se fait par diffusion instantanée. Un signal est soitprésent pendant toute la réaction, soit absent.

L’occurrence d’un ou plusieurs signaux démarre une réaction du programmeESTEREL. Cette réaction consiste pour le programme à modifier son état etéventuellement à produire des signaux de sortie. Entre deux réactions leprogramme ESTEREL est totalement inactif, il n’y a aucun code exécuté.

2.2 Les primitives ESTEREL

Le langage contient des instructions impératives classiques, un opérateur deparallélisme, un opérateur d’échappement et des instructions de manipulationd’événements, que l’on appelle instructions temporelles.

2.2.1 Les primitives impératives

L’instruction “nothing ” est l’instruction vide, elle ne fait rien. L’instruction“halt ” ne fait rien non plus mais bloque l’exécution du programme indéfiniment.L’affectation est réalisée par l’opérateur “:= ”. L’opération “call ” permet l’appel deprocédure externe, c’est-à-dire des procédures écrites dans un autre langage, lelangage C par exemple. La structure conditionnelle “if <expr> then <instr 1>

148 Annexes


else <instr 2> end ” se comporte comme dans les langages classiques, et laboucle infinie est réalisé par l’instruction “loop <instr> end ”. On peut définir unbloc d’instructions nommé avec la déclaration “trap <nom_bloc> ... end ” et ensortir à tout moment grâce à “exit < nom_bloc> ”. Le signe “; ” réalise leséquencement des opérations, et “|| ” le parallélisme.

Sur une machine infiniment rapide, toutes ces instructions sont exécutées sansprendre de temps, à l’exception de “halt ” qui ne se termine jamais. Deux blocsd’instructions séquentielles mis en parallèles démarrent simultanément. Lesaffectations (“:= ”) et comparaisons (test d’égalité “=”) de valeurs ayant un type nondéfini dans le langage (c’est-à-dire autre que entier, booléen ou caractères) sonttraduites à la compilation en appels de procédures externes, qui doivent avoir étéécrites lors de la définition de ce type. Ces procédures, ainsi que toutes lesprocédures externes (celles appelées par “call ” en particulier), doivent avoir unedurée d’exécution courte. En effet si une de ces procédures exécutait une opérationbloquante, du type lecture d’E/S, l’hypothèse de synchronisme ne serait plusvérifiée. D’autre part il faut éviter toutes les constructions qui peuvent ne pasavoir une exécution finie, par exemple le compilateur refusera de compiler laséquence

loopX:=X+1;

end;

car elle ne se termine jamais.

2.2.2 Les primitives temporelles

Les primitives temporelles manipulent des signaux. Il faut distinguer troistypes de signaux :

1. les signaux d’entrée, en provenance de l’extérieur du programme;

2. les signaux de sortie, que le programme émet vers l’extérieur;

3. les signaux internes, qui sont émis et écoutés uniquement à l’intérieur duprogramme, afin de communiquer entre différents composants.

Toutes les primitives temporelles s’appliquent à ces trois type de signaux, àl’exception de l’émission d’un signal qui ne peut se faire sur un signal d’entrée.

L’émission d’un signal “SIG” avec la valeur “val ” et d’un signal pur “SIGPUR” sefait en écrivant

emit SIG(val);emit SIGPUR

L’accès à la valeur courante d’un signal valué est possible grâce à l’opérateur “?”;ainsi “?SIG” donnera la valeur avec laquelle le signal SIG a été émis.

Annexes 149


On peut tester la présence d’un signal, de façon non bloquante, à l’aide de lacommande

present <signal> then <instr 1> else <instr 2> end

Une primitive permet de limiter dans le temps l’exécution de son corps :

do<instr>

watching <exp> <signal>

où <exp> est une expression numérique. La séquence d’instructions exécutéesentre le “do” et le “watching ” est interrompue lors de la <exp> ème occurrence dusignal SIG. Cette primitive se termine aussi lorsque le corps (entre “do” et“watching ”) a été totalement exécuté.

Il existe d’autres instructions temporelles, qui peuvent toutes être réécrites àpartir des deux primitives “present ” et “do-watching ” et des primitivesimpératives de base. Ces instructions dites dérivées sont donc fournies uniquementpour faciliter l’écriture des programmes. Nous noterons maintenant “<occ> ” pour“<expr> <signal> ”.

On peut ajouter une clause “timeout ” à la primitive “do-watching ” :

do<instr 1>

watching <occ>timeout

<instr 2>end

ce qui équivaut à

trap <id> indo

<instr 1>;exit <id>

watching <occ>;<instr 2>

end

Une autre garde temporelle importante est l’instruction “upto ” qui ne setermine que sur réception de l’événement et non si son corps se termine :

do<inst>

upto <occ>ce qui équivaut à

do<instr>;halt

watching <occ>

L’attente d’une occurrence simple s’écrit :

await <occ>

ce qui équivaut à

dohalt

watching <occ>

Il possible d’attendre plusieurs occurrences simultanément, à l’aide del’instruction “await-case ” :

150 Annexes


awaitcase <occ1> do <instr 1>case <occ2> do <instr 2>

...end

La première des occurrences satisfaite détermine l’action à effectuer. Une seuleaction est effectuée, même si plusieurs occurrences sont présentes, et lesoccurrences sont testées dans l’ordre d’apparition dans le code, ce qui maintient ledéterminisme. L’expansion en primitives de base est ici un peu plus complexe, ellecommence par une attente parallèle de toutes les occurrences, puis on choisitl’action à exécuter par une cascade de “present-else ”.

Deux instructions permettent le déclenchement répétitif d’actions :

loop<instr>

each <occ>ce qui équivaut à

et

every <occ> do<instr>

endce qui équivaut à

loopdo

<instr>upto <occ>

end

await <occ>loop

<instr>each <occ>

2.2.3 L’exécution de tâches asynchrones

Il est possible de lancer une exécution asynchrone depuis un programmeESTEREL, on appelle une exécution de ce type une tâche. Elle est initiée par uneréaction, et se termine dans une autre. La façon dont les tâches sont gérées auniveau du système ne concerne pas le langage.

Le programmeur doit déclarer les tâches avec le mot clef task . De la mêmefaçon qu’une procédure, elle peut avoir des paramètres d’entrée et de sortie. Lemodule ESTEREL est avertit de la terminaison de son exécution par l’occurenced’un signal particulier, de type ‘return ’, qui lui aussi doit avoir été déclaré, et quiest associé à la tâche au moment de son démarrage :

% déclarationtask MaTache(integer)(integer);return Fin;% invocationexec MaTache(X)(1) return Fin;

Cette commande peut être vue comme étant équivalente à l’appel d’uneprocédure suivie d’une attente de signal. En fait elle est plus riche que cela, carune tâche peut être tuée lorsqu’elle a été lancée dans un bloc d’instruction

Annexes 151


interrompu par un exit ou un watching . L’interface du protocole dedémarrage/destruction de tâche est dépendant de l’environnement.

2.3 Les paradoxes temporels

L’hypothèse de synchronisme peut engendrer certains paradoxes, qui nepeuvent être exécutés. Le compilateur a donc la charge de les détecter et d’enavertir le programmeur.

Cas du signal qui ne peut être ni présent ni absent :

present Snothing

elseemit S

end

Si le signal n’est pas présent, alors il est émis, donc il est présent, donc il n’estpas émis... Cette séquence est incohérente.

Cas du signal à valeur auto-modifiable :

emit S(0);emit S(?S+1)

Le signal S est émis avec la valeur 0, puis avec une combinaison de lui-même.L’expression “?S=?S+1” n’est pas calculable, puisque à chaque fois qu’on lui trouveune valeur, elle est modifiée.

Globalement ces problèmes se produisent lorsque la présence ou la valeur d’unsignal dépend d’eux-mêmes. Ces situations d’erreur de causalité sont détectées parune analyse statique du code, lors de la phase de compilation.

2.4 La compilation d’un programme ESTEREL

La compilation d’un programme ESTEREL produit un automate.

Une analyse du code permet de déterminer un ensemble d’états du programmeESTEREL : à chaque instruction d’arrêt du programme correspond un état, etlorsqu’il existe plusieurs blocs d’instructions mis en parallèle (opérateur ‘||’),chacune des combinaisons de leurs sous-états constitue un état global. Les actionsde l’automate sont factorisées et associées aux états dans lesquels elles doiventêtre exécutées. A partir de chacun de ces états, le compilateur détermine l’étatsuivant et les signaux à émettre en fonction des signaux en entrée. C’est lors decette phase que sont détectées les erreurs de causalités.

L’automate ainsi calculé est écrit en langage OC, qui est un standard pour ladescription d’automates. Ce langage est utilisé, entre autres, pour la compilationdes langages synchrones LUSTRE et SIGNAL. Il existe des outils permettant, àpartir de ce code, de visualiser graphiquement l’automate, et d’en faire des

152 Annexes


minimisations et autres opérations formelles sur les automates. A l’aide de cesoutils, des analyses et preuves sont appliquées afin de certifier que l’automatecorrespond à ses spécifications.

Le code OC est ensuite traduit en code exécutable. Différents environnementscibles sont disponibles : des interfaces pour la simulation permettent de tester descomportements qui n’ont pu être vérifiés à l’étape précédente, ou bien des langagesde programmation classiques (C et C++). L’automate produit en langage C nepossède aucune interface, qui reste donc totalement à la charge du développeur.Par contre la traduction en C++ offre une bibliothèque de classes réalisant desinterfaces de base [BOUL94], et la programmation par objets permet audéveloppeur de rajouter ses propres classes à cette bibliothèque, afin d’étendre sespossibilités d’interfaçage. C’est pour cette raison que nous utilisons, dans nosdéveloppements, le traducteur de OC en C++.

Annexes 153


3 Code ESTEREL de la gestion des tâches

%% InterruptMgr.strl% Manages physical interrupts, produces ClockTick%module InterruptMgr:

procedure save_thCtx()(), % a thread is interrupted, save its context restore_thCtx()(), % end of the interruption, restore its context push_ItCtx()(), % an IT interrupts another IT, push context on stack pop_ItCtx()(); % an IT restarts, pop context from stack

input Interrupt( integer ), EndInterrupt;

output ClockTick, EnterInterrupt, ExitInterrupt, AsyncInterrupt( integer );

var itLevel : integer in loop await Interrupt; run InterruptHandlers; present (AsyncInterrupt) then %---- enter interrupt mode call save_thCtx()(); emit EnterInterrupt; itLevel := 1; trap Interrupting in loop await [Interrupt or EndInterrupt]; present (Interrupt) then run InterruptHandlers; end present ; present (AsyncInterrupt) then present ( not EndInterrupt) then call push_ItCtx()(); itLevel := itLevel + 1; end present ; else present (EndInterrupt) then itLevel := itLevel - 1; if (itLevel = 0) then exit Interrupting; %---- exit interrupt mode else call pop_ItCtx()(); end if ; end present end present ; end loop ; end trap ; call restore_thCtx()(); emit ExitInterrupt; end present ; end loop ;end var ;end module

154 Annexes


%% InterruptHandlers.strl% select Synchronous/Asynchronous interrupt management%module InterruptHandlers:

constant TIMER_8254 : integer;

input Interrupt( integer );

output ClockTick, AsyncInterrupt( integer );

% Only one synchronous interrupt : the clock if (?Interrupt = TIMER_8254) then emit ClockTick; else emit AsyncInterrupt( ?Interrupt ); end if ;

end module

Annexes 155


%% SysMode.strl% Redirects software interrupts and exceptions to current thread, if% not in interrupt mode%module SysMode:

type ThreadRef;

function runningThread(): ThreadRef;

input Trap, TrapRet, Exception, ExceptionRet, EnterInterrupt, ExitInterrupt;

output ThreadTrap( ThreadRef ), ThreadTrapRet( ThreadRef ), ThreadException( ThreadRef ), ThreadExceptionRet( ThreadRef );

relation Trap # TrapRet # Exception # ExceptionRet, EnterInterrupt # ExitInterrupt;

loop trap ThreadMode in loop await case Trap do emit ThreadTrap( runningThread() ); case Exception do emit ThreadException( runningThread() ); case TrapRet do emit ThreadTrapRet( runningThread() ); case ExceptionRet do emit ThreadExceptionRet( runningThread() ); end await ; end loop ; || [ await immediate EnterInterrupt; exit ThreadMode; ] end trap ; await ExitInterrupt; end loop ;

end module

156 Annexes


%% TimerMgr.strl% Timer List Manager%module TimerMgr:

type TimerParamList, TimeVal;

constant nullTimeVal : TimeVal;

procedure enqueueTimers( TimeVal, boolean )( TimerParamList ), dequeueTimers( TimeVal, boolean, boolean )( TimerParamList );

input DelTimer( TimerParamList ), SetTimer( TimerParamList );

output NextTimeOut( TimeVal ), NoTimer;

signal newNext in

% Add or Delete a Timer var next:=nullTimeVal : TimeVal, isNext, wasNext : boolean, TimersOut : TimerParamList, noMore:= true : boolean in loop await [SetTimer or DelTimer]; present SetTimer then % We assert delay > 0, filter should be done upwards call enqueueTimers( next, isNext )( ?SetTimer ); noMore := false ; if (isNext) then % The newly inserted timer becomes the awaited one emit newNext; end if ; end present ; present DelTimer then call dequeueTimers( next, noMore, wasNext )( ?DelTimer ); if ( wasNext ) then % The deleted timer was the awaited one emit newNext; end if ; end present ; if (noMore) then emit NoTimer; else present newNext then emit NextTimeOut( next ); end present ; end if ; end loop ; end var ;

end signal ;end module

Annexes 157


%% TimeGuard.strl% Timer Watchdog%module TimeGuard:

type TimerParamList, TimeVal;

constant deltaT : TimeVal, nullTimeVal : TimeVal;

function diffTimeVal( TimeVal, TimeVal ): integer, TimeInc( TimeVal ): TimeVal;

procedure dequeueTimersAt( TimeVal, boolean, TimerParamList )( TimeVal ), initCurrentTime()();

input ClockTick, NextTimeOut( TimeVal ), NoTimer;

output TimerOut( TimerParamList );

relation NextTimeOut # NoTimer;

signal ClockVal( TimeVal ) in

% Manage the current time value call initCurrentTime()(); every ClockTick do emit ClockVal( TimeInc( deltaT ) ); end every ; || var nextTimer : TimeVal, delay : integer, TimersOut : TimerParamList, noMore:= true : boolean in loop do await immediate NextTimeOut; nextTimer := ?NextTimeOut; trap Waiting in loop % wait until next timer delay := diffTimeVal(nextTimer, ?ClockVal); if (delay > 0) then await delay ClockTick; end if ; % remove all timer at a given time call dequeueTimersAt(nextTimer,noMore,TimersOut)(nextTimer); emit TimerOut( TimersOut ); await ClockTick; if (noMore) then exit Waiting; end if ; end loop ; end trap ; watching [NoTimer or NextTimeOut];

158 Annexes


% if NoTimer, wait until new timer, % else await the new timer end loop ; end var ;


Annexes 159


%% thSuspend.strl% Suspend’s behavior specifications%module thSuspend:

constant ActiveInit : boolean;

input % thread will delete itself next time it will leave the processor DeleteThread, % mask or unmask stop operations MaskSuspend, UnMaskSuspend, Suspend, Resume;

output BeReadySuspend, BeUnReadySuspend;

signal maskedSuspend, initSuspend, shouldSuspend, shouldResume in

do loop await [MaskSuspend and not UnMaskSuspend]; do sustain maskedSuspend; watching [UnMaskSuspend and not MaskSuspend]; end loop ; || var suspCnt:=0 : integer in % suspend counter if ( not ActiveInit) then % created SUSPENDED suspCnt := -1; emit shouldSuspend; emit initSuspend; end if ; loop await [Suspend or Resume]; present Suspend then present not Resume then suspCnt := suspCnt -1; if (suspCnt = -1) then emit shouldSuspend; end if ; end present ; else present Resume then suspCnt := suspCnt +1; if (suspCnt = 0) then emit shouldResume; end if ; end present ; end present ; end loop ; end var ; || loop await immediate shouldSuspend; trap suspended in present maskedSuspend then do await [UnMaskSuspend and not MaskSuspend]; emit BeUnReadySuspend;

160 Annexes


watching shouldResume timeout exit suspended end ; else present not initSuspend then emit BeUnReadySuspend; end present ; end present ; await shouldResume; emit BeReadySuspend; end trap ; end loop ; watching DeleteThread; emit BeReadySuspend;


Annexes 161


%% thStop.strl% stop’s behavior%module thStop:

input % thread will delete itself next time it will leave the processor DeleteThread, % mask or unmask stop operations MaskStop, UnMaskStop, % mainly used when actor is STARTED or STOPPED Stop, Start;

output DeleteStop, BeReadyStop, BeUnReadyStop;

signal maskedStop in

do loop await [MaskStop and not UnMaskStop]; do sustain maskedStop; watching [UnMaskStop and not MaskStop]; end loop ; || loop await [Stop and not Start]; trap stopped in present maskedStop then do await [UnMaskStop and not MaskStop]; emit BeUnReadyStop; watching [Start and not Stop] timeout exit stopped end ; else emit BeUnReadyStop; end present ; await [Start and not Stop]; emit BeReadyStop; end trap ; end loop ; watching DeleteThread; emit BeReadyStop; emit DeleteStop;


162 Annexes


%% thSleep.strl% Sleep’s behavior specifications%module thSleep:

constant K_ETIMEOUT : integer, % a timeout on a waiting request has occured K_EABORT : integer, % a waiting request has been aborted K_OK : integer; % a waiting request ended normally

input % thread will delete itself next time it will leave the processor DeleteThread, % mask or unmask abort operations MaskAbort, UnMaskAbort, % the current or next abortable waiting call is to be aborted % (if Abort is not masked) Abort, % sleep actions Awake, Sleep( integer ), % a timer is over TimerOut;

output BeReadySleep, BeUnReadySleep, % termination of a waiting request Awaken( integer ), % set a timer on SetTimer : integer, % cancel running timer DelTimer : integer;

var abort := 0 : integer, maskedAbort := false : boolean, delay : integer in

loop await [Abort or Sleep or MaskAbort or UnMaskAbort]; present MaskAbort then present not UnMaskAbort then maskedAbort := true ; end present ; else present UnMaskAbort then maskedAbort := false ; end present ; end present ; present Sleep then % no new Sleep can occur while the thread is asleep if (?Sleep <> 0) then if ((abort > 0) and ( not maskedAbort)) then abort := abort - 1; emit Awaken( K_EABORT ); else % if ((abort>0 and maskedAbort) or abort=0), then sleep delay := ?Sleep; emit SetTimer( delay ); emit BeUnReadySleep; trap sleeping in loop do await [ MaskAbort or UnMaskAbort or Awake or TimerOut or Abort ];

Annexes 163


present MaskAbort then present not UnMaskAbort then maskedAbort := true ; end ; else present UnMaskAbort then maskedAbort := false ; end end present ; present Awake then % the waited event has occured emit DelTimer( delay ); emit Awaken( K_OK ); exit sleeping; end present ; present TimerOut then % the timer expired emit Awaken( K_ETIMEOUT ); exit sleeping; end present ; present Abort then if not maskedAbort then % abort current waiting operation emit DelTimer( delay ); emit Awaken( K_EABORT ); exit sleeping; else % this Abort will be treated later abort := abort + 1; end if ; end present ; watching DeleteThread; present DeleteThread then % abort current waiting operation emit DelTimer( delay ); emit Awaken( K_EABORT ); exit sleeping; end present ; end loop ; end trap ; emit BeReadySleep; end if ; else emit Awaken( K_ETIMEOUT ); end if ; else present Abort then abort := abort + 1; end present ; end present ; end loop ;

end var ;end module

164 Annexes


%% thMain.strl% Thread’s global state : ready or blocked ?%module thMain:

constant ActiveInit : boolean; % false if thread is created in suspended mode

input % signals from thStop, thSuspend, thSleep BeReadyStop, BeUnReadyStop, BeReadySuspend, BeUnReadySuspend, BeReadySleep, BeUnReadySleep, % thread will delete itself next time it will leave the processor DeleteThread, % mask or unmask delete operations MaskDelete, UnMaskDelete;

output % the thread is ready to execute Active, % status goes from Active (and possibly Running) to Blocked state Blocked, % the thread is to be freed Free;

relation BeReadyStop # BeUnReadyStop, BeReadySleep # BeUnReadySleep, BeReadySuspend # BeUnReadySuspend;

signal readyStop, readySleep, readySuspend in

% initial status ?if (ActiveInit) then emit Active;end ;

trap EXIT in [ if ( not ActiveInit) then await BeReadySuspend; end if ; loop do sustain readySuspend; watching BeUnReadySuspend; await BeReadySuspend; end loop ;] || loop do sustain readyStop; watching BeUnReadyStop; await BeReadyStop; end loop ; || loop do sustain readySleep; watching BeUnReadySleep; await BeReadySleep; end loop ; || % compute global state [ if (ActiveInit) then

Annexes 165


await [BeUnReadyStop or BeUnReadySuspend or BeUnReadySleep]; end if ; loop trap blocked in emit Blocked; loop await [BeReadyStop or BeReadySuspend or BeReadySleep]; present (readyStop and readySuspend and readySleep) then exit blocked; end present ; end loop ; end trap ; emit Active; await [BeUnReadyStop or BeUnReadySuspend or BeUnReadySleep]; end loop ;] || % manage deletion requests loop await case MaskDelete do trap maskedDelete in [ await immediate DeleteThread; await immediate UnMaskDelete; exit EXIT; ] || [ await immediate UnMaskDelete; exit maskedDelete; ] end trap ; case DeleteThread do exit EXIT; end await ; end loop ;end trap ;emit Free; % automaton should not be stimulated any more


166 Annexes


%% thTrapExc.strl% Manages software interrupts and exceptions%module thTrapExc:

constant supervisorThread : boolean;

input Trap, TrapRet, Exception, ExceptionRet;

output EnterSystemMode, ExitSystemMode;

relation Trap # TrapRet # Exception # ExceptionRet;

var sysLevel : integer in if (supervisorThread) then emit EnterSystemMode; halt ; end if ; loop await [Trap or Exception]; trap SystemMode in sysLevel := 1; emit EnterSystemMode; loop await case [Trap or Exception] do sysLevel := sysLevel+1; case [TrapRet or ExceptionRet] do sysLevel := sysLevel-1; if (sysLevel=0) then emit ExitSystemMode; exit SystemMode; end if ; end await ; end loop ; end trap ; end loop ; end var ;

end module

Annexes 167


%% SchedBase.strl% Generic scheduling management%module SchedBase:

type ThreadRef, ThreadRefList, ThreadDesc, ThreadUpd;

constant dummyThread : ThreadRef;

procedure schedulerInit()(), scheduleUpdate()( ThreadUpd ), scheduleAdd()( ThreadRefList ), scheduleDel()( ThreadRefList ), scheduleChoose( boolean, ThreadRef )(), freeThread()( ThreadRefList );

function createThread( ThreadDesc ): ThreadRef;

input CreateThread( ThreadDesc ), UpdateThread( ThreadUpd ), Free( ThreadRefList ), Active( ThreadRefList ), Blocked( ThreadRefList ), EnterInterrupt, ExitInterrupt;

output ThreadCreated( ThreadRef ), ThreadDeleted( ThreadRefList ), Run( ThreadRef );

inputoutput TestSchedule;

relation EnterInterrupt # ExitInterrupt;

% initialazations : one thread in kernel (dummyThread), currently running call schedulerInit()(); present not TestSchedule then emit Run( dummyThread ); end present ;

loop await [CreateThread or Free or UpdateThread or Active or Blocked]; present CreateThread then emit ThreadCreated( createThread( ?CreateThread ) ); end present ; present Free then call freeThread()( ?Free ); emit ThreadDeleted( ?Free ); emit TestSchedule; end present ; present UpdateThread then call scheduleUpdate()( ?UpdateThread ); emit TestSchedule; end present ; present Active then

168 Annexes


call scheduleAdd()( ?Active ); emit TestSchedule; end present ; present Blocked then call scheduleDel()( ?Blocked ); emit TestSchedule; end present ; end loop ;|| var running:=dummyThread, old : ThreadRef, change : boolean in loop do await immediate TestSchedule; loop old := running; call scheduleChoose( change, running )(); if (change) then emit Run( running ); end if ; await TestSchedule; end loop ; watching EnterInterrupt; trap InterruptMode in [ await immediate TestSchedule; await ExitInterrupt; emit TestSchedule; ] || [ await immediate ExitInterrupt; exit InterruptMode; ] end trap ; end loop ; end var ;

end module

Annexes 169


%% TimeSlice.strl% Chorus specific scheduling : time slicing%module TimeSlice:

type ThreadRefList, ThreadRef;

procedure sliceOver()( ThreadRef );

function timeSlice( ThreadRef ): integer, IncludedIn( ThreadRef, ThreadRefList ): boolean;

input ClockTick, Run( ThreadRef ), Free( ThreadRefList ), Blocked( ThreadRefList );

output TestSchedule;

loop trap InSlice in var quantum : integer, thIn : ThreadRef in quantum := timeSlice( ?Run ); if (quantum > 0) then % the thread has a limited interval to run thIn := ?Run; trap WaitSlice in [ await quantum ClockTick; call sliceOver()( thIn ); % processor attribution should emit TestSchedule; % be reconsidered ] || [ every Free do if (IncludedIn( thIn, ?Free )) then exit WaitSlice; end if ; end every ] || [ every Blocked do if (IncludedIn( thIn, ?Blocked )) then exit WaitSlice; end if ; end every ] end trap ; end if end var ; || await Run; exit InSlice; end trap ; end loop ;

end module

170 Annexes

Documents

aris 6 France Telecom CNET - olivier.potonniee.online.frolivier.potonniee.online.fr/public/docs/These.pdf · L’utilisation de l’approche synchrone dans la programmation des systèmes