Lecture de traces Fonctionnement du lecteurFonctionnement du lecteur

Étant donnée la structure d’une trace TAPE, la lecture de traces est une opéra-tion un peu compliquée. Le principal problème à résoudre est dû à la segmentaopéra-tion du fichier d’événements en blocs, laquelle impose un interclassement des

événe-ments des différents blocs afin de garantir la production d’événeévéne-ments consécutifs lors d’une lecture séquentielle de la trace.

Le lecteur de traces TAPE utilise des lecteurs spécialisés dans le traitement d’un bloc d’événements triés. Il y a un tel lecteur spécialisé pour chaque pro-ducteur de blocs d’événements, i.e. un par tâche. Les événements fournis par ces lecteurs sont insérés par le lecteur de traces dans des échéanciers qui permettent de délivrer les événements dans l’ordre voulu (figure 2.4 page suivante).

Le lecteur de traces autorisant une lecture bidirectionnelle de la trace, il gère deux échéanciers, l’un pour les événements à venir et l’autre pour les événements passés. Pour produire un événement, le lecteur de traces effectue donc les opéra-tions suivantes :

– insertion de l’événement courant dans l’échéancier opposé au sens de lec-ture, i.e. dans le passé si la lecture se fait vers l’avant et dans le futur dans le cas contraire9;

– obtention d’un événement du lecteur spécialisé ayant produit cet événement et insertion de cet événement dans l’échéancier correspondant au sens de lecture ;

– récupération du premier événement de cet échéancier, qui devient l’événe-ment courant.

Outre les événements, le lecteur de traces gère des objets représentant les dif-férentes entités d’exécution d’une application, i.e. les processeurs, les tâches et les fils d’exécution.

Le lecteur de traces utilise également un dernier objet, le gestionnaire de topo-logie, qui représente la topologie de l’application obtenue en analysant le fichier de topologie d’une trace TAPE. Le gestionnaire de topologie permet par exemple au lecteur de traces de retrouver la destination d’un lien de communication lors de la lecture d’un événement de communication.

9: Afin de ne pas conserver toute la trace dans l’échéancier, le lecteur de traces détruit d’abord dans l’échéancier tout événement produit par le lecteur ayant produit l’événement à insérer.

2.3. SUPPORT DES APPLICATIONS SUR TRANSPUTER

(a) Organisation du lecteur de trace.

18227 14039 18227 14039 10217 10174 10217 10174 13211 12720 12720 16998 12234 12234 13211 11403

(b) Manipulation des échéanciers lors d’une lecture en avant.

FIG. 2.4. – Lecture d’une trace TAPE. Le lecteur de traces utilise un lecteur spé-cialisé par bloc d’événements du fichier d’événements. Les événements fournis par ces lecteurs sont insérés dans des échéanciers pour interclasser les événe-ments afin de les délivrer dans le bon ordre.

Classes d’événements

Le lecteur de traces transforme les événements contenus dans la trace en objets afin qu’ils soient faciles à manipuler.

La hiérarchie de classes qui est définie correspond à la classification des évé-nements présentée dans le tableau 2.4 page 103. Elle est donnée dans la figure 2.5 page suivante qui indique les différentes classes existantes ainsi que les événe-ments traités par chacune d’entre elles.

2.3.3 Simulation

Le but de la réalisation de simulateur étant d’effectuer une étude de faisa-bilité de l’application des principes choisis pour la lecture de traces et la si-mulation, celui-ci ne traite qu’un sous-ensemble du modèle de programmation d’OUF/TRITA.

États des objets manipulés

Comme nous l’avons dit au § 2.2 page 94, le simulateur fait évoluer l’état du système simulé en fonction des événements qu’il reçoit. L’état d’une application OUF/TRITA est un graphe dont les sommets représentent les tâches de l’applica-tion et les arêtes les liens de communical’applica-tion entre ces tâches. Les fils d’exécul’applica-tion et les sémaphores ne sont pas simulés.

On notera que même si les processeurs des machines sur lesquelles les traces TAPE sont prises peuvent être multiprogrammés il est impossible au traceur de connaître les instants où se fait l’ordonnancement car la prise de traces se fait au niveau de l’application et non du système. En conséquence les seules informations qu’il puisse donner sur les changements d’état d’une tâche concernent ses com-munications. On distingue ainsi déjà trois états possibles pour une tâche : elle est dans l’état actif lorsqu’elle n’est pas en train de communiquer, dans l’état

com-municant lorsqu’elle est effectivement en train de communiquer avec une autre

tâche (c’est-à-dire lorsque les données sont effectivement échangées entre deux tâches ayant établi un rendez-vous) et dans l’état inactif lorsqu’elle est bloquée alors qu’elle cherche à communiquer avec une tâche qui n’est pas encore arrivée

2.3. SUPPORT DES APPLICATIONS SUR TRANSPUTER

TapeEvent

Send TSend EndSend Receive TReceive EndReceive

Wait EndWait Alt NAlt EndAlt

SemInit SemP SemGOk SemG SemV Run Stop TapeTaskEvent TapeThreadEvent TapeCommEvent TapeSemEvent TapeAltEvent TapeSysEvent TskBth TskDth ThdBth ThdDth

FIG. 2.5. – Hiérarchie des classes d’événements de TAPE. Les classes sur fond rouge sont des classes abstraites.

au rendez-vous. Les deux derniers états possibles sont l’état mort et l’état

inuti-lisé qui indiquent respectivement que la tâche concernée a fini de s’exécuter¹⁰ou qu’elle n’est pas encore née (mais le simulateur connaît son existence puisqu’il dispose de la topologie de l’application).

Les liens de communication peuvent a priori être dans un des deux états

sui-10: Le comportement par défaut du simulateur est de conserver une tâche morte afin qu’il soit possible d’accéder aux statistiques qu’il lui associe, voir plus loin.

vants : l’état communicant lorsqu’ils sont en train de transporter des données et l’état inutilisé dans le cas contraire. En fait le simulateur génère non seulement ces deux états mais en ajoute également deux autres : un lien est dit dans l’état

inactif lorsque des données sont attendues sur ce lien (que ce soit en émission ou

en réception) et dans l’état mort lorsqu’il ne peut plus être utilisé (i.e. lorsque la tâche qui peut émettre sur ce lien est morte). L’utilisateur dispose ainsi d’infor-mations plus précises sur l’état de son application à un instant donné. L’utilisation de ces états supplémentaires dans des visualisations permet aussi de donner une vision bien meilleure des communications puisque non seulement la tâche mais également le lien concerné par une communication changent d’état.

Les tableaux 2.5 et 2.6 récapitulent les différents états que peuvent prendre les tâches et les liens de communication.

Nom Signification Unused Inutilisé Dead Mort Idle Inactif Talking Communicant Busy Actif Nom Signification Unused Inutilisé Dead Mort Idle Inactif Talking Communicant

TAB. 2.5. – États donnés aux tâches

par le simulateur d’OUF/TRITA.

TAB. 2.6. – États donnés aux liens

par le simulateur d’OUF/TRITA.

Attributs associés aux objets simulés

Chacun de ces objets, et le graphe lui-même, est doté d’attributs permettant de connaître non seulement l’état du système mais également d’autres informations utiles pour l’évaluation des performances ou la compréhension de l’application.

2.3. SUPPORT DES APPLICATIONS SUR TRANSPUTER

Les tableaux 2.7, 2.8 et 2.9 page suivante listent les attributs maintenus par le simulateur. (Les noms utilisés sont ceux que l’on retrouve au cours de l’utilisation de l’environnement, aussi sont-ils en anglais.)

Attribut Signification

Clock Date de la dernière modification.

ClockUnits Unité dans laquelle sont exprimées les dates

TAB. 2.7. – Attributs du graphe d’état maintenus par le simulateur d’OUF/TRITA.

Attribut Signification

Clock Date de la dernière modification

State État du nœud

Name Identificateur du nœud dans l’application (donne éga-lement son type)

Nickname Surnom du nœud donné par l’utilisateur

Protagonist Nœud avec qui une communication est en cours

PercentBusy Pourcentage de temps passé dans l’étatBusy PercentIdle Pourcentage de temps passé dans l’étatIdle PercentTalking Pourcentage de temps passé dans l’étatTalking

TAB. 2.8. – Attributs des nœuds maintenus par le simulateur d’OUF/TRITA.

On remarquera qu’étant donné que la topologie de l’application est connue a

priori11 il est possible d’initialiser le simulateur avec un graphe correspondant à cette topologie. Les différents objets de ce graphe sont alors initialisés dans l’état

Unuseden attendant leur première utilisation.

11: À l’exception des informations concernant les fils d’exécution dont la création et la destruc-tion sont entièrement dynamiques.

Attribut Signification

Clock Date de la dernière modification

State État du lien de communication

Name Identificateur du lien dans l’application

Origin Surnom du nœud d’où part le lien

Destination Surnom du nœud vers lequel va le lien

Usage Nombre d’utilisateurs du lien

Traffic Volume de données en cours de transfert

TotalTraffic Volume de données global transféré

PercentUnused Pourcentage de temps passé dans l’étatUnused PercentIdle Pourcentage de temps passé dans l’étatIdle PercentTalking Pourcentage de temps passé dans l’étatTalking

TAB. 2.9. – Attributs des liens maintenus par le simulateur d’OUF/TRITA.

Fonctionnement du simulateur

L’annexe A.1 page 197 décrit précisément le traitement effectué par le simu-lateur pour chacun des types d’événements qu’il connaît. Elle illustre également les changements d’états produits par ces événements.

2.4 Support des applications PVM

PVM est une bibliothèque de programmation parallèle qui permet de considé-rer un ensemble quelconque de machines hétérogènes comme une machine lèle (homogène), permettant de développer et d’exécuter des applications paral-lèles avec un investissement matériel réellement minimal.

Les applications PVM peuvent être de type MIMD ou SPMD et sont consti-tuées par des tâches communiquant par envoi de messages. Le modèle d’envoi de message supporte l’envoi bloquant ainsi que les réceptions bloquante et non-bloquante. Il comporte en outre des opérations globales ou de groupe permettant l’échange complexe d’informations entre un ensemble de tâches. Le modèle PVM