Prise et format de trace Prise de tracePrise de trace

Les applications écrites avec OUF/TRITA peuvent être tracées à l’aide du tra-ceur logiciel TAPE (ARROUYE 1992). Celui-ci est constitué par une version ins-trumentée de la bibliothèque de programmation OUF/TRITA et par une tâche de collecte de trace à laquelle chaque tâche utilisateur est connectée (figure 2.2 page suivante).

Les fonctions instrumentées produisent des événements qui sont stockés loca-lement dans l’espace d’adressage des tâches afin de minimiser le coût de la prise de trace en évitant toute communication pendant cette prise. Lorsqu’un tampon d’événements est plein, ou en fin d’exécution, les événements sont transmis à la tâche de collecte qui les écrit dans le fichier de trace. La tâche de collecte de trace a également la responsabilité du démarrage et de la terminaison de l’application tracée.

Les horloges des différents processeurs de la machine sur laquelle s’exécute l’application n’étant pas forcément identiques le traceur commence par les syn-chroniser, i.e. par calculer les différences des dates données par chacune d’entre elles. Cette synchronisation associée à des données expérimentales indiquant la dérive de chaque horloge au cours du temps est utilisée pour dater les événe-ments avec suffisamment de précision pour éviter des incohérences dans la trace6

6: Un exemple classique d’incohérence est le cas où les événements de la trace indiquent que la date de réception d’un message est antérieure à sa date d’émission ; dans ce cas il est impossible de savoir ce qui s’est passé dans le système et la trace a de fortes chances d’être inutilisable pour

Tâche TAPEmaître Tâche de l’application

Trace

FIG. 2.2. – Organisation des tâches d’une application tracée avec TAPE. Chaque tâche de l’application est connectée à une tâche maître qui récupère ses événements pour les écrire dans le fichier de trace et se charge du démarrage et de la terminaison de l’application.

(MAILLET 1994, MAILLET et TRON 1995). On obtient alors une référence de temps globale (JÉZÉQUEL 1990) pour tous les processeurs.

Il n’est pas nécessaire de modifier le source d’une application pour produire des traces : lorsqu’on souhaite obtenir une trace, il suffit de refaire l’édition de liens de l’application avec la bibliothèque OUF/TRITA instrumentée pour que

2.3. SUPPORT DES APPLICATIONS SUR TRANSPUTER

l’application produise une trace. L’utilisateur peut également spécifier dynami-quement quels événements doivent être tracés au cours de l’exécution et produire ses propres événements (à charge pour lui ensuite de fournir le code nécessaire à leur interprétation lorsqu’ils sont exploités à des fins d’analyse).

Format de trace

Une trace TAPE est constituée d’un ensemble de fichiers décrivant d’une part la structure de l’application et d’autre part les événements produits au cours de l’exécution ; on appellera cet ensemble fichier de tracepar abus de langage. Les différents fichiers constituant la trace sont (figure 2.3 page suivante) :

– un fichier de topologie décrivant l’architecture physique de la machine ainsi que l’architecture logique de l’application ;

– un fichier d’index indiquant pour chaque tâche le début d’un bloc d’événe-ments lui appartenant dans le fichier d’événed’événe-ments ;

– un fichier d’événements organisé par blocs : chaque bloc correspond aux événements d’une tâche, les événements d’un bloc donné étant ordonnés par dates croissantes et doublement chaînés afin de permettre une lecture bidirectionnelle de la trace.

Alors que le fichier de topologie est textuel, les fichiers d’index et d’événe-ments sont des fichiers binaires afin de minimiser leur temps d’accès et l’espace nécessaire à la conservation des traces.

Les événements ont un format variable suivant les informations associées à l’action qu’ils représentent. Tout événement comporte cependant un en-tête don-nant des informations communes à tous les types d’événements, à savoir le type de l’événement, sa date, l’identification de l’entité qui l’a produit (sous la forme d’un quadruplet donnant les identificateurs de processeurs physique et virtuel⁷, de tâche et de fil d’exécution) ou encore la date de production de l’événement.

7: Le système utilisé comporte un routeur logiciel (DEBBAGEet al. 1991) qui autorise la dé-claration d’autant de processeurs que souhaité et la spécification du placement de ces processeurs virtuels sur les processeurs physiques effectivement disponibles pour l’exécution.

Fichier de topologie Fichier d’index

(Événements d’un processeur)

Fichier d’événements

FIG. 2.3. – Composition d’une trace TAPE.

Événements

Chaque fonction de la bibliothèque OUF/TRITA génère un ou plusieurs évé-nements décrivant l’action effectuée par cette fonction : alors que la création ou la mort d’un fil provoquent un changement d’état immédiat, l’émission d’un mes-sage est une opération bloquante à laquelle correspondent deux événements, le premier lorsque le processus émetteur prend rendez-vous avec un destinataire et le second lorsque ce rendez-vous est fini.

De même que l’on peut classer les différentes fonctions en catégories dis-tinctes, les événements appartiennent à des classes déterminées comme les évé-nements de processus (naissance et mort d’une entité), de communication (envoi et réception d’un message), ou encore de synchronisation (prise et libération d’un sémaphore). Le tableau 2.4 page ci-contre présente les événements générés par TAPEclassés par catégorie8.

8: Les noms des événements ont été simplifiés afin de ne pas surcharger la présentation. Les noms véritables des événements sont les noms donnés une fois mis en majuscules et précédés de

2.3. SUPPORT DES APPLICATIONS SUR TRANSPUTER

Catégorie Nom Action

Processus TskBth Naissance d’une tâche

TskDth Mort d’une tâche Fils ThdBth Naissance d’un fil

ThdDth Mort d’un fil

Run Lancement d’un fil

Stop Arrêt d’un fil Communication Send Début d’envoi

TSend Début d’envoi avec délai

EndSend Fin d’envoi

Receive Début de réception

TReceive Début de réception avec délai

EndReceive Fin de réception

Timeout Expiration du délai de communication Sémaphores SemInit Initialisation d’un sémaphore

SemP Prise de sémaphore

SemGOk Test et prise de sémaphore

SemG Fin de prise de sémaphore

SemV Libération de sémaphore Alternatives Alt Alternative bloquante

NAlt Alternative non bloquante

EndAlt Fin d’alternative Attente Wait Attente (sommeil)

EndWait Fin d’attente

TAB. 2.4. – Événements générés par TAPE.

2.3.2 Lecture de traces