Précédent : Interface de programmation parallèle
et Remonter : Fondements scientifiques Suivant :
Domaines
d'applications
Le non déterminisme apparent des exécutions parallèles induit des erreurs fugitives particulièrement difficiles à détecter. En effet, des programmes parallèles produisant des résultats déterministes sont susceptibles d'emprunter des chemins d'exécution différents en raison de conditions différentes dans l'environnement d'exécution (par exemple s'il y a régulation dynamique de charge). Dans ces conditions, des erreurs fugitives sont susceptibles d'apparaître, erreurs qui ne se produisent pas à toutes les exécutions ou disparaissent lorsque des moyens d'investigation sont mis en oeuvre (traceur, débogueur). La technique classique pour mettre au point les programmes à comportement non déterministe est d'enregistrer [[8]], au cours d'une exécution initiale, une trace. Cette trace sera utilisée pour forcer le programme à suivre le même chemin durant les exécutions suivantes pour lesquelles il sera ainsi possible d'utiliser tous les outils de débogage existants [[7]].
Un traceur logiciel [[6]], dans notre contexte de processus légers communiquants doit être à même d'identifier tous les objets clés (et les événements qui leur sont liés) d'un programme parallèles (les processeurs, les processus légers, les ports de communications, les messages, les variables de synchronisation, etc.).
La prise de trace concerne essentiellement l'ordonnancement des fils d'exécution, avec pour chaque processus léger son identité, le début, la fin et la cause des périodes de suspension de son exécution. S'y ajoutent des informations permettant de reconstituer l'historique des communications. Il faut résoudre divers problèmes d'identification des fils d'exécution, d'observabilité de leur ordonnancement, d'atomicité des événements et de gestion des tampons de trace. Le traceur doit gérer l'absence de référence temporelle globale.
Il est très difficile d'analyser l'origine de dégradations de
performances de programmes parallèles. En effet, celles-ci
peuvent trouver leur origine dans l'algorithme implanté,
l'environnement d'exécution ou l'architecture matérielle de la
machine. Il est aussi très difficile d'intégrer ces différents
types d'informations pour obtenir une vision globale de
l'exécution du programme parallèle, car ils relèvent de
différents niveaux d'abstraction de l'exécution. La visualisation
des exécutions parallèles [[6]] est délicate en raison
du grand nombre d'objets mis en oeuvre lors de ces exécutions.
Les propriétés que doivent vérifier les environnements de
visualisation d'exécutions parallèles sont principalement
l'extensibilité en terme de fonctionnalités
(nouvelles représentations visuelles ou sonores) et en terme de
taille de l'objet visualisé .