PCO1 - Laboratoire 2 : Exclusion mutuelle par attente active.

PCO1 - Laboratoire 2 : Exclusion mutuelle par attente active. 1.0 Généré par Doxygen 1.6.1 Thu Mar 18 20 :32 :52 2010

Table des matières 1 PCO1 - Laboratoire 2 : Exclusion mutuelle par attente active. 1 2 Index des fichiers 3 2.1 Liste des fichiers....................................... 3 3 Documentation des fichiers 5 3.1 Référence du fichier cours.c................................. 5 3.1.1 Description détaillée................................. 5 3.1.2 Description...................................... 5 3.1.3 Compilation..................................... 5 3.1.4 Remarques...................................... 6 3.1.5 Documentation des macros.............................. 6 3.1.5.1 ASM_BARRIERE............................. 6 3.1.6 Documentation des fonctions............................. 6 3.1.6.1 cours.................................... 6 3.2 Référence du fichier cours.h................................. 7 3.2.1 Description détaillée................................. 7 3.2.2 Description...................................... 7 3.2.3 Documentation des fonctions............................. 7 3.2.3.1 cours.................................... 7 3.3 Référence du fichier dekker.c................................. 9 3.3.1 Description détaillée................................. 9 3.3.2 Description...................................... 9 3.3.3 Compilation..................................... 9 3.3.4 Remarques...................................... 9 3.3.5 Documentation des macros.............................. 10 3.3.5.1 ASM_BARRIERE............................. 10 3.3.6 Documentation des fonctions............................. 10 3.3.6.1 dekker................................... 10

ii TABLE DES MATIÈRES 3.3.6.2 dekker_debut_section_critique...................... 10 3.3.6.3 dekker_fin_section_critique........................ 10 3.3.7 Documentation des variables............................. 10 3.3.7.1 NOMBRE_ITERATIONS......................... 10 3.4 Référence du fichier dekker.h................................. 11 3.4.1 Description détaillée................................. 11 3.4.2 Description...................................... 11 3.4.3 Documentation des fonctions............................. 11 3.4.3.1 dekker................................... 11 3.5 Référence du fichier labo2.c................................. 12 3.5.1 Description détaillée................................. 12 3.5.2 Description...................................... 12 3.5.3 Compilation..................................... 12 3.5.4 Remarques...................................... 12 3.5.5 Documentation des fonctions............................. 13 3.5.5.1 main.................................... 13 3.6 Référence du fichier peterson.c................................ 14 3.6.1 Description détaillée................................. 14 3.6.2 Description...................................... 14 3.6.3 Compilation..................................... 14 3.6.4 Remarques...................................... 14 3.6.5 Documentation des macros.............................. 15 3.6.5.1 ASM_BARRIERE............................. 15 3.6.6 Documentation des fonctions............................. 15 3.6.6.1 peterson.................................. 15 3.6.6.2 peterson_debutsectioncritique...................... 15 3.6.6.3 peterson_finsectioncritique....................... 15 3.7 Référence du fichier peterson.h................................ 16 3.7.1 Description détaillée................................. 16 3.7.2 Description...................................... 16 3.7.3 Documentation des fonctions............................. 16 3.7.3.1 peterson.................................. 16 3.8 Référence du fichier psleep.h................................. 17 3.9 Référence du fichier rapport.txt................................ 18 3.9.1 Description détaillée................................. 18 3.9.2 Introduction...................................... 18

TABLE DES MATIÈRES iii 3.9.2.1 Problème posé............................... 18 3.9.2.2 Choix d implémentation.......................... 18 3.9.3 Implémentations & Comparaisons.......................... 19 3.9.4 Machines/O.S. utilisés................................ 19 3.9.4.1 Machine 1................................. 19 3.9.4.2 Machine 2................................. 19 3.9.5 Résultats des mesures................................ 20 3.9.5.1 Machine 1................................. 20 3.9.5.2 Machine 2................................. 23 3.9.6 Conclusion...................................... 27

Chapitre 1 PCO1 - Laboratoire 2 : Exclusion mutuelle par attente active.

2 PCO1 - Laboratoire 2 : Exclusion mutuelle par attente active.

Chapitre 2 Index des fichiers 2.1 Liste des fichiers Liste de tous les fichiers avec une brève description : cours.c............................................... 5 cours.h............................................... 7 dekker.c............................................... 9 dekker.h............................................... 11 labo2.c............................................... 12 peterson.c.............................................. 14 peterson.h.............................................. 16 psleep.h............................................... 17

4 Index des fichiers

Chapitre 3 Documentation des fichiers 3.1 Référence du fichier cours.c #include "cours.h" Macros #define ASM_BARRIERE Fonctions int cours (void) 3.1.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 18.03.2009 Version: 1.0.0 3.1.2 Description Ce fichier contient le corps des en-têtes des fonctions présentes dans le fichier cours.c, plus toutes les fonctionnalités privées utiles que pour l éxécution de cet algorithme en particulier. 3.1.3 Compilation Voici la commande complète de compilation : gcc -O3 -Wall -D_REENTRANT -std=c99 -c -fmessage-length=0 -lpthread -MMD -MP -MF"cours.d" -MT"cours.d" -o"cours.o" "cours.c"

6 Documentation des fichiers 3.1.4 Remarques Pour résoudre le problème d accès concurrent à la mémoire des processeurs multicoeurs, nous incluons la fonction Barriere(). Source : http ://asm.inightmare.org/opcodelst/index.php?op=sfence Attention, ce programme n affiche qu un nombre en virgule flottante comme résultat. Il s agit en fait du nombre de secondes qui se sont écoulées pendant l exécution de l algorithme. Cela est dû au fait que nous avons exécuté des scripts shell qui automatisent les exécutions de cet algorithme et qui récupèrent leurs résultats pour les mettre dans un fichier texte. Il nous faut donc uniquement un nombre, pour pouvoir ensuite le traiter dans les graphiques. Définition dans le fichier cours.c. 3.1.5 Documentation des macros 3.1.5.1 #define ASM_BARRIERE Définition à la ligne 32 du fichier cours.c. 3.1.6 Documentation des fonctions 3.1.6.1 int cours (void) Cette fonction permet de lancer l algorithme 2,2 du cours ainsi que d en connaître le temps d exéction final en secondes, sachant qu il est composé de 2 threads et que chacun d entre-eux effectue 12500000 itérations. Attention, les 2 tâches doivent avoir exactement le même nombre d itérations, car cet algorithme (non optimal) possède un couplage fort entre les tâches, et elle s exécutent forcément l une après l autre. Donc quand une tâche termine une itération, elle passe le jeton et attend qu on lui le repasse, mais si cette autre tâche est déjà terminée, cette dernière ne pourra plus jamais repasser ce jeton. La première tâche est donc en attente infinie. Renvoie: Un entier permettant de connaître l état de terminaison (erreur ou non). Définition à la ligne 241 du fichier cours.c. Référencé par main().

3.2 Référence du fichier cours.h 7 3.2 Référence du fichier cours.h #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <stdbool.h> #include <math.h> Fonctions int cours (void) 3.2.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 05.03.2009 Version: 1.0.0 3.2.2 Description Ce fichier décrit les en-têtes des fonctions du fichier cours.c. Il contient l algorithme 2.2 du cours qui permet de gérer une section critique entre threads de façon sûre et sans accès concurrents à des variables partagées. Notons toutefois que cet algorithme induit un couplage très fort entre les tâches qui s éxécutent en pseudo-parallélisme, ce qui fait qu il y a une alternance systématique entre les 2 tâches. Ce n est donc pas un algorithme optimal, mais il a le mérite de fonctionner. Définition dans le fichier cours.h. 3.2.3 Documentation des fonctions 3.2.3.1 int cours (void) Cette fonction permet de lancer l algorithme 2,2 du cours ainsi que d en connaître le temps d exéction final en secondes, sachant qu il est composé de 2 threads et que chacun d entre-eux effectue 12500000 itérations. Attention, les 2 tâches doivent avoir exactement le même nombre d itérations, car cet algorithme (non optimal) possède un couplage fort entre les tâches, et elle s exécutent forcément l une après l autre. Donc quand une tâche termine une itération, elle passe le jeton et attend qu on lui le repasse, mais si cette autre tâche est déjà terminée, cette dernière ne pourra plus jamais repasser ce jeton. La première tâche est donc en attente infinie. Renvoie: Un entier permettant de connaître l état de terminaison (erreur ou non).

8 Documentation des fichiers Définition à la ligne 241 du fichier cours.c. Référencé par main().

3.3 Référence du fichier dekker.c 9 3.3 Référence du fichier dekker.c #include "dekker.h" Macros #define ASM_BARRIERE Fonctions void dekker_debut_section_critique (int tache) void dekker_fin_section_critique (int tache) int dekker (void) Variables volatile const int NOMBRE_ITERATIONS = 5000000 3.3.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 18.03.2009 Version: 1.0.0 3.3.2 Description Ce fichier contient le corps des en-têtes des fonctions présentes dans le fichier dekker.c, plus toutes les fonctionnalités privées utiles que pour l éxécution de cet algorithme en particulier. 3.3.3 Compilation Voici la commande complète de compilation : gcc -O3 -Wall -D_REENTRANT -std=c99 -c -fmessage-length=0 -lpthread -MMD -MP -MF"dekker.d" -MT"dekker.d" -o"dekker.o" "dekker.c" 3.3.4 Remarques Pour résoudre le problème d accès concurrent à la mémoire des processeurs multicoeurs, nous incluons la fonction Barriere(). Source : http ://asm.inightmare.org/opcodelst/index.php?op=sfence Attention, ce programme n affiche qu un nombre en virgule flottante comme résultat. Il s agit en fait du nombre de secondes qui se sont écoulées pendant l exécution de l algorithme. Cela est dû au fait que nous avons exécuté des scripts shell qui automatisent les exécutions de cet algorithme et qui récupèrent leurs

10 Documentation des fichiers résultats pour les mettre dans un fichier texte. Il nous faut donc uniquement un nombre, pour pouvoir ensuite le traiter dans les graphiques. Définition dans le fichier dekker.c. 3.3.5 Documentation des macros 3.3.5.1 #define ASM_BARRIERE Définition à la ligne 32 du fichier dekker.c. 3.3.6 Documentation des fonctions 3.3.6.1 int dekker (void) Cette fonction permet de lancer l algorithme de Dekker ainsi que d en connaître le temps d exéction final en secondes, sachant qu il est composé de 2 threads et que chacun d entre-eux effectue respectivement 10000000 et 15000000 d itérations. Renvoie: Un entier permettant de connaître l état de terminaison (erreur ou non). Définition à la ligne 204 du fichier dekker.c. Référencé par main(). 3.3.6.2 void dekker_debut_section_critique (int tache) Permet de faire les instructions nécessaires pour entrer en section critique, selon l algorithme de Dekker. Paramètres: tache -> Le numéro de la tâche qui souhaite entrer en SC. Définition à la ligne 114 du fichier dekker.c. 3.3.6.3 void dekker_fin_section_critique (int tache) Permet de faire les instructions pour sortir de la section critique, selon l algorithme de Dekker. Paramètres: tache -> Le numéro de la tâche qui souhaite sortir de la SC. Définition à la ligne 135 du fichier dekker.c. 3.3.7 Documentation des variables 3.3.7.1 volatile const int NOMBRE_ITERATIONS = 5000000 Définition à la ligne 40 du fichier dekker.c.

3.4 Référence du fichier dekker.h 11 3.4 Référence du fichier dekker.h #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <stdbool.h> #include <math.h> #include <time.h> Fonctions int dekker (void) 3.4.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 05.03.2009 Version: 1.0.0 3.4.2 Description Ce fichier décrit les en-têtes des fonctions du fichier dekker.c. Il contient l algorithme de Dekker qui permet de gérer une section critique entre threads de façon sûre et sans accès concurrents à des variables partagées. Définition dans le fichier dekker.h. 3.4.3 Documentation des fonctions 3.4.3.1 int dekker (void) Cette fonction permet de lancer l algorithme de Dekker ainsi que d en connaître le temps d exéction final en secondes, sachant qu il est composé de 2 threads et que chacun d entre-eux effectue respectivement 10000000 et 15000000 d itérations. Renvoie: Un entier permettant de connaître l état de terminaison (erreur ou non). Définition à la ligne 204 du fichier dekker.c. Référencé par main().

12 Documentation des fichiers 3.5 Référence du fichier labo2.c #include "dekker.h" #include "cours.h" #include "peterson.h" #include <time.h> Fonctions int main (int argc, char argv) 3.5.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 18.03.2009 Version: 1.0.0 3.5.2 Description Ce fichier contient le programme principal de notre laboratoire. Il permet de lancer un des trois algorithmes, que l on spécifiera par un argument donné au programme ; 1 pour l algorithme de Dekker, 2 pour l algorithme de Peterson et 3 pour l algorithme 2.2 du cours. Le résultat est un nombre en virgule flottante indiquant le nombre de secondes écoulées durant l exécution de l algorithme choisi. La raison de ce choix réside dans le fait que nous automatisons ensuite l exécution de ce programme avec un script shell qui enregistre chaque résultat dans un fichier texte, ligne après ligne, que nous reprenons ensuite afin de traiter les données sous forme de graphiques. 3.5.3 Compilation Voici la commande complète de compilation : gcc -O3 -Wall -D_REENTRANT -std=c99 -c -fmessage-length=0 -lpthread -MMD -MP -MF"labo2.d" -MT"labo2.d" -o"labo2.o" "labo2.c" 3.5.4 Remarques Définition dans le fichier labo2.c.

3.5 Référence du fichier labo2.c 13 3.5.5 Documentation des fonctions 3.5.5.1 int main (int argc, char argv) Programme principal de test des algorithmes. On peut spécifier en argument quel algorithme nous voulons lancer. Paramètres: argc Le numéro de l algorithme que nous voulons lancer (1, 2, ou 3) argv Arguments récupérés sous forme de chaîne de caractères. Définition à la ligne 40 du fichier labo2.c. Références cours(), dekker(), et peterson().

14 Documentation des fichiers 3.6 Référence du fichier peterson.c #include "peterson.h" Macros #define ASM_BARRIERE Fonctions void peterson_debutsectioncritique (int tache) void peterson_finsectioncritique (int tache) int peterson (void) 3.6.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 18.03.2009 Version: 1.0.0 3.6.2 Description Ce fichier contient le corps des en-têtes des fonctions présentes dans le fichier peterson.h. 3.6.3 Compilation Voici la commande complète de compilation : gcc -O3 -Wall -D_REENTRANT -std=c99 -c -fmessage-length=0 -lpthread -MMD -MP -MF"peterson.d" -MT"peterson.d" -o"peterson.o" "peterson.c" 3.6.4 Remarques Attention, si on ne met pas les variables globales partagées par les threads en "volatile", on permet le compilateur de faire des optimisations dessus, et notamment de changer une boucle while(condition) en while(true) alors que la variable condition est justement une ressource partagée entre threads et très importante. En effet, le compilateur ne sait pas qu on va partager la variable entre plusieurs threads et pourrait de plus mettre ces variables en cache dans les registres du processeur, ce qui serait une catastrophe. Source : http ://www.drdobbs.com/cpp/184403766 Pour résoudre le problème d accès concurrent à la mémoire des processeurs multicoeurs, nous incluons la fonction Barriere(). Source : http ://asm.inightmare.org/opcodelst/index.php?op=sfence Attention, ce programme n affiche qu un nombre en virgule flottante comme résultat. Il s agit en fait du nombre de secondes qui se sont écoulées pendant l exécution de l algorithme. Cela est dû au fait que nous avons exécuté des scripts shell qui automatisent les exécutions de cet algorithme et qui récupèrent leurs

3.6 Référence du fichier peterson.c 15 résultats pour les mettre dans un fichier texte. Il nous faut donc uniquement un nombre, pour pouvoir ensuite le traiter dans les graphiques. Définition dans le fichier peterson.c. 3.6.5 Documentation des macros 3.6.5.1 #define ASM_BARRIERE Définition à la ligne 40 du fichier peterson.c. 3.6.6 Documentation des fonctions 3.6.6.1 int peterson (void) Cette fonction permet, comme son nom l indique, de lancer l algorithme de Peterson sur 2 tâches simultanées. Elle crée donc 2 threads et les lance simultanément. Ces 2 threads ne sont rien d autre que Tache0 et Tache1, dont les définitions se trouvent ci-dessus. Renvoie: Un entier indiquant l état de terminaison de l algorithme (erreur ou non). Définition à la ligne 220 du fichier peterson.c. Référencé par main(). 3.6.6.2 void peterson_debutsectioncritique (int tache) Cette fonction permet de faire les actions nécessaires lors de l entrée en section critique, c est-à-dire mettre en place un verrou efficace et inalterable permettant d empêcher tout entité d accéder ensuite aux variables partagées, après l appel de cette fonction. @þaram tache La tache qui veut entrer en section critique. Définition à la ligne 133 du fichier peterson.c. 3.6.6.3 void peterson_finsectioncritique (int tache) Cette fonction permet de relâcher le verrou, c est-à-dire de redonner le droit à d autres tâches de rentrer en section critique. Le jeton d accès aux ressources critiques est alors à nouveau disponible. Paramètres: tache La tâche qui veut quitter la section critique. Définition à la ligne 148 du fichier peterson.c.

16 Documentation des fichiers 3.7 Référence du fichier peterson.h #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <stdbool.h> #include "psleep.h" Fonctions int peterson (void) 3.7.1 Description détaillée Auteur: Pierre-Dominique Putallaz & Lazhar Farjallah Date: 05.03.2009 Version: 1.0.0 3.7.2 Description Ce fichier décrit les en-têtes des fonctions du fichier peterson.c. Il contient l algorithme de Peterson qui permet de gérer une section critique entre threads de façon sûre et sans accès concurrents à des variables partagées. Définition dans le fichier peterson.h. 3.7.3 Documentation des fonctions 3.7.3.1 int peterson (void) Cette fonction permet de relâcher le verrou, c est-à-dire de redonner le droit à d autres tâches de rentrer en section critique. Le jeton d accès aux ressources critiques est alors à nouveau disponible. Paramètres: tache La tâche qui veut quitter la section critique. Cette fonction permet, comme son nom l indique, de lancer l algorithme de Peterson sur 2 tâches simultanées. Elle crée donc 2 threads et les lance simultanément. Ces 2 threads ne sont rien d autre que Tache0 et Tache1, dont les définitions se trouvent ci-dessus. Renvoie: Un entier indiquant l état de terminaison de l algorithme (erreur ou non). Définition à la ligne 220 du fichier peterson.c. Référencé par main().

3.8 Référence du fichier psleep.h 17 3.8 Référence du fichier psleep.h

18 Documentation des fichiers 3.9 Référence du fichier rapport.txt 3.9.1 Description détaillée Rapport Auteur: Date: Version: Pierre-Dominique Putallaz & Lazhar Farjallah 17.03.2010 1.0.0 Nous présentons ici un rapport exposant la démarche du laboratoire ainsi que les explications associées. Cette documentation est tapée dans un fichier texte séparé car il nous parait non approprié d introduire une aussi grande quantité de commentaires dans un fichier source. Tous les détails ommis dans les commentaires des fichiers sources se retrouvent donc dans ce rapport. 3.9.2 Introduction Dans ce laboratoire de programmation concurrente, nous mettons en oeuvre trois algorithmes d exclusion mutuelle par attente active. Nous prenons ensuite une série de mesures des temps d exécution de ces derniers. Nous évaluons ensuite la baisse de performance liée à certains de ces algorithmes. Enfin, nous comparons ces différents mécanismes d exclusion mutuelle grâce à des graphiques basés sur les mesures effectuées. 3.9.2.1 Problème posé Le but de ce laboratoire est de comparer les performances de divers algorithmes d exclusion mutuelle par attente active. Nous sommes intéressés à comparer les 3 implémentations différentes suivantes : l algorithme de Dekker l algorithme de Peterson l algorithme 2.2 du cours Une fois ces algorithmes codés en C et une fois les mesures effectuées, nous nous intéressons aux résultats sous forme graphique et commentons ces derniers. 3.9.2.2 Choix d implémentation Nous présentons maintenant les différents choix d implémentation que nous avons décidé de réaliser. Tout d abord, nous avons décidé de créer 3 jeu de fichiers séparés pour chaque algorithme, contenant un fichier source (.c) et un d en-tête (.h). Ensuite, nous avons décidé de créer 2 fonctions distinctes pour les tâches, à savoir Tache_0 et Tache_1 pour chaque algorithme. La raison de ce choix réside dans le fait que nous voulions pouvoir effectuer différentes actions dans le 2 tâches. Par exemple, dans la première tâche, nous effectuons un nombre d itérations n, alors que dans la deuxième tâche, nous effectuons un nombre d itérations de m, avec n non-égal à m. De plus, nous savons pertinemment que dans les cas réels, 2 tâches qui s exécutent en concurrence ne seront jamais exactement les mêmes. Puis nous avons décidé de faire les mesures des algorithmes sur 2 machines différentes. Nous avons donc pour cela créé un répositoire svn dédié à ce laboratoire afin qu on puisse synchroniser le code entre les

3.9 Référence du fichier rapport.txt 19 2 machines, et n avoir qu une seule version de ce code, afin qu il soit exactement identique sur les 2 machines. Enfin, nous avons choisi d automatiser la phase de mesure des performances en créeant des scripts automatisés qui lancent un nombre de fois voulu les exécutables et reportent ensuite les résultats dans un fichier texte. Ce dernier choix nous a grandement été utile pour importer ensuite un grand jeu de données dans excel. On aura donc pû effectuer pas moins de 500 mesures par algorithme et par machine. 3.9.3 Implémentations & Comparaisons Nous développons maintenant la manière dont nous avons comparé les 3 algorithmes. Chacun de ces algorithmes effectue en tout 25 millions d itérations. Ces itérations sont réparties entre 2 tâches, à chaque fois. Dans l algorithme du cours, 12,5 millions d itérations sont effectuées par tâche, alors que dans les 2 autres algorithmes, la première tâche en effectue 10 millions, alors que la 2ème en effectue 15 millions. Dans l algorithme du cours, nous sommes obligés de faire exactement le même nombre d itérations pour chaque tâche car comme l algorithme possède un couplage fort (ping-pong entre les tâches), si elles ne possèdent pas le même nombre d itérations, c est comme si on jouait au ping-pong et qu au bout d un moment notre adversaire ne nous renvoyait plus la balle car il serait parti, et nous attendrions que cette balle revienne infiniment... A la fin de l exécution de chacun de ces algorithmes, la console affiche le temps d exécution écoulé en secondes. Nous avons compilé le même code source final avec exactement les mêmes options de compilation sur 2 machines différentes pour en relever des mesures. Les mesures ont été effectuées par un script shell automatisant non seulement le lancement des exécutables, mais également l enregisrement de leur sortie (c est-à-dire le temps d exécution des algorithmes) dans des fichiers textes (.txt) afin de pouvoir ensuite les importer facilement dans un tableur de type Excel. En ce qui concerne la compilation, nous avons décidé de mettre un niveau d optimisation O3, en prenant soin de mettre les variables partagées en volatile pour éviter des problèmes lors de l optimisation de ces variables. Nous avons également, après réception d un e-mail de notre professeur, intégré la fonction Barriere() permettant d assurer la consistance des variables sur des architectures multiprocesseurs. 3.9.4 Machines/O.S. utilisés Nous avons en tout utilisé 2 machines différentes pour effectuer les mesures. Nous détaillons leurs caractéristiques dans les 2 sections suivantes. 3.9.4.1 Machine 1 O.S. : GNU/Linux Ubuntu i686 (32 bits) Processeur : Intel Core Duo T2500 (2M Cache, 2.00 GHz, 667 MHz FSB) Année : 2006 Détails : http ://ark.intel.com/product.aspx?id=27236 3.9.4.2 Machine 2 O.S. : GNU/Linux Gentoo x86_64 (64 bits) Processeur : Intel Core 2 Duo T9550 (6M Cache, 2.66 GHz, 1066 MHz FSB)

20 Documentation des fichiers Année : 2009 Détails : http ://ark.intel.com/product.aspx?id=37130 3.9.5 Résultats des mesures Nous exposons maintenant le résultat des mesures effectuées sur les deux machines précitées sous forme de graphiques. Nous donnons pour chaque graphique la moyenne, la médiane ainsi que l écart- type des mesures. Pour chacun des graphiques, l axe x représente le numéro de la mesure de 1 à 500, l axe y représente le temps en secondes, de 0 à 10. Chaque mesure représente 25 millions d itérations. Il y a 500 mesures et il y a 6 jeu de mesures. Au total, c est donc 25e6 500 6 = 75 milliards d itérations effectuées en tout et pour tout, soit 12,5 milliards d itérations par algorithme testé. 3.9.5.1 Machine 1 3.9.5.1.1 Algorithme de Dekker, machine 1 Moyenne : 3.89 secondes Médiane : 3.93 secondes Écart-type : 0.55 secondes Durée totale du test : 32 minutes et 25 secondes Nombre moyen d itérations par seconde : 6,42 millions FIG. 3.1 Algorithme de Dekker, machine 1 On voit dans ce premier test que les résultats sont assez éparpillés autour d une moyenne de 3.89 secondes.

3.9 Référence du fichier rapport.txt 21 On peut donc en déduire que l algorithme de Dekker sur cette machine n est pas très constant. On notera également certaines valeurs atypique, mais très rares, comme par exemple un temps d exécution de moins de 1 seconde vers la mesure n 300. Il est intéressant de se demander d où peut prvenir une telle mesure atypique. La réponde qu on peut donner est qu il est possible qu à ce moment du test, le processeur a pu être dédié à 100% sans interruption à l exéction de l algorithme. On voit donc que l ordonnanceur n est absolument pas régulier, chose que nous savions et que ce test prouve. 3.9.5.1.2 Algorithme de Peterson, machine 1 Moyenne : 5.60 secondes Médiane : 5.54 secondes Écart-type : 0.67 secondes Durée totale du test : 46 minutes et 40 secondes Nombre moyen d itérations par seconde : 4,46 millions FIG. 3.2 Algorithme de Peterson, machine 1 Ici nous voyons que, par rapport à la figure 3.1 (Dekker), l algorithme de Peterson est un peu plus lent sur cette machine avec une moyenne de 5,60 secondes, contre une moyenne de 3,89 secondes pour Dekker. Les mesures sont également plus éparpillées (écart-type plus grand que ce lui de Dekker). On en conclut donc que sur cette machine, l algorithme de Peterson est moins performant que l algorithme de Dekker. Ne nous étonnons pas de ce constat, car il faut bien avoir à l esprit que beaucoup de choses entrent en compte, notamment le fait que cette machine est relativement vieille (2006) et qu elle est dotée de la toute première génération de processus à double coeurs. Nous verrons de plus dans les tests la machine 2, très différente, que les conclusions ne sont absolument pas les mêmes, avec pourtant un code source et des options de compilation parfaitement similaires. Notons encore qu il aura fallu ici attendre 46 minutes pour que les 500 exécutions de l algorithme se terminent.

22 Documentation des fichiers 3.9.5.1.3 Algorithme 2.2 du cours, machine 1 Moyenne : 6.76 secondes Médiane : 6.79 secondes Écart-type : 0.14 secondes Durée totale du test : 56 minutes et 20 secondes Nombre moyen d itérations par seconde : 3,70 millions FIG. 3.3 Algorithme 2.2 du cours, machine 1 Dans ce 3ème test pour la machine 1, nous voyons cette fois que les points sont beaucoup moins éparpillés. On peut donc dire ici que l algorithme 2.2 du cours est beaucoup plus constant. Par contre, n oublions pas que cet algorithme induit un couplage fort entre les tâches, et qu il n est pas optimal à ce niveau. Cependant, il est intéressant de voir que, malgré cela, il est beaucoup plus constant dans son exécution sur cette machine, par rapport aux 2 autres algorithmes qui le sont beaucoup moins. Notons finalement que cet algorithme, sur cette machine, est celui qui aura été le moins performant, en ce qui concerne le temps d exécution. Il aura en effet fallu attendre ici plus de 56 minutes pour exécuter la totalité des 500 exécutions en série. 3.9.5.1.4 Résultat global, machine 1 Nous proposons maintenant de faire un petit récapitulatif des 3 algorithmes testés pour cette première machine. Nous avons pour cela créé un diagramme en colonnes avec en x les algorithmes testés, et en y le temps d exécution total, en minutes.

3.9 Référence du fichier rapport.txt 23 FIG. 3.4 Résultat global, machine 1 On voit clairement ici, qu en moyenne, l algorithme de Dekker sera nettement plus performant. En effet, il est pratiquement 2 fois plus rapide que l algorithme 2.2 du cours. De plus, choses étonnante vu que l algorithme de Peterson s exprime plus simplement que celui de Dekker, ce dernier n en reste pas moins performant. Nous verrons, dans les résultats de la deuxième machine, que ce diagramme est exactement inversé. 3.9.5.2 Machine 2 3.9.5.2.1 Algorithme de Dekker, machine 2 Moyenne : 2.65 secondes Médiane : 2.24 secondes Écart-type : 1.2 secondes Durée totale du test : 22 minutes et 05 secondes Nombre moyen d itérations par seconde : 9.43 millions

24 Documentation des fichiers FIG. 3.5 Algorithme de Dekker, machine 2 La première chose qui saute aux yeux dans ce graphique, c est l éparpillement des points, autrement dit l écart-type du jeu de données. En effet, il est ici de 1,2 secondes, ce qui est de tous les algorithmes testés, le moins constant sur cette machine. Sur la première machine, les résultats étaient également assez éparpillés, mais plus de 2 fois moins. On en conclut donc que sur cette machine, l algorithme de Dekker n est vraiment pas constant dans sont temps d exécution. Il peut en effet tout aussi bien s exécuter entre 1 et 2 secondes qu entre 3 à 6 secondes, par exemple. Nous notons également des valeurs atypiques. Notons finalement, que par rapport à la première machine, ici l algorithme de Dekker est exécuté 1,5 fois plus rapidement. Nous verrons au final qu en plus de cela, pour cette machine, cet algorithme est le moins performant, à l inverse de la machine 1. 3.9.5.2.2 Algorithme de Peterson, machine 2 Moyenne : 1.85 secondes Médiane : 1.85 secondes Écart-type : 0.03 secondes Durée totale du test : 15 minutes et 25 secondes Nombre moyen d itérations par seconde : 13,51 millions

3.9 Référence du fichier rapport.txt 25 FIG. 3.6 Algorithme de Peterson, machine 2 Ce qui est tout de suite frappant dans ce résultat graphique, c est la constance des mesures. En effet, on pourrait pratiquement remplacer les points du graphique par une ligne droite continue. Cela est très positif comme résultat, et s approche même d un idéal qu on aimerait toujours avoir dans ce genre de tests. De plus, on voit également que cet algorithme est plus performant que celui de Dekker sur cette machine, alors que sur l autre machine, c était l inverse. Ajoutons encore que des valeurs atypiques se dessinent nettement, à fréquence régulière, par l apparition de points nettement démarqués, environ toutes les 60 exécutions. Ceci est certainement dû au fait que l O.S. ou autre programme quelconque doit effectuer une certaine tâche à fréquence régulière, ce qui consomme temporairement un peu plus de ressources. Mais si on résonne sur l ensemble du test, cela représente évidemment une goutte d eau dans l océan. Finalement, si nous regardons le résultat de cet algorithme pour la machine 1 dans la figure 3.2, on voit que les choses sont bien différentes. Cela peut s expliquer par la différence d O.S. (Ubuntu 32 bits pour la machine 1, Gentoo 64 bits pour la machine 2), mais également du fait que sur la machine 2, le processeur est bien plus récent, et que le multicoeur est certainement beaucoup mieux géré que dans la première machine, qui, rappelons-le, possède la première génération de processeurs dual core. 3.9.5.2.3 Algorithme 2.2 du cours, machine 2 Moyenne : 1.46 secondes Médiane : 1.45 secondes Écart-type : 0.04 secondes Durée totale du test : 12 minutes et 10 secondes Nombre moyen d itérations par seconde : 17,12 millions

26 Documentation des fichiers FIG. 3.7 Algorithme 2.2 du cours, machine 2 Etonamment, l algorithme 2.2 du cours sur cette machine présente un résultat pratiquement semblable à celui de Peterson exposé juste avant. On notera en effet denouveau la constance de l algorithme au niveau de son temps d exécution, ainsi que les valeurs atypiques à fréquence régulière. Notons encore que cet algorithme, pour cette machine, est le plus performant, ce qui était totalement l inverse avec l autre machine.

3.9 Référence du fichier rapport.txt 27 3.9.5.2.4 Résultat global, machine 2 FIG. 3.8 Résultat global, machine 2 L échelle étant la même que le le graphique global de la machine 1, on voit immédiatement que la machine 2, comme on s y attendait, est bien plus performante que la première. Cela n est pas du tout surprenant, car c est presque 4 ans qui séparent les dates de sortie des 2 machines, ce qui est énorme dans l échelle du temps de l informatique. Par contre, chose assez surprenante, ici le diagramme est totalement l inverse de celui de la machine 1. En effet, ici, plus on va vers la droite, plus l algorithme est performant, alors qu avec la machine 1, plus on va vers la droite, moins l algorithme est performant. Encore une fois, cela vient certainement du fait que les O.S. sont différents sur les 2 machines, et que les processeurs également. On retiendra au final que l algorithme de Peterson est le meilleur ici, si on ne tient pas compte de l algorithme 2.2 du cours, qui rappelons-le n est pas une solution viable, mais qui est présenté ici à titre de comparaison. Notons encore qu en général, sur cette machine, les algorithmes sont de 2 à 4 fois plus rapides que sur l autre. 3.9.6 Conclusion Ce laboratoire nous aura permis ce voir à quel point les choses peuvent être différentes d une machine à l autre, lorsque l on s attaque à des problèmes de concurrence. Il aura été très intéressant de comprendre

28 Documentation des fichiers une des règles esssentielles de la programmation concurrence, celle de toujours considérer toutes les situations possibles. En effet, l ordonnanceur est tellement imprévisible d une machine à l autre, qu on ne peut jamais s appuyer sur un tel critère. Ce qui ressort fortement de ce travail, c est l opposition des résutats entre les 2 machines de test. En effet, pour un code et des options de compilation rigoureusement identiques, les résultats sont de loin homogènes entre les 2 machines. Encore une fois, cela appuie le principe qui dit qu il faut toujours envisager tous les scénarios possible lorsque l on développe un programme concurrent. On ne peut jamais rien prévoir, et il faut une fois pour toutes bannir cette idée de notre esprit. L autre côté intéressant de ce laboratoire est que les 2 machines de test possèdent les deux un O.S. de type GNU/Linux, mais pas semblables. On aura en effet dédié ce laboratoire à l environnement Linux, ce qui est une bonne chose car on sait quel monopole prennent des O.S. comme Windows dans le monde informatique. Nous aurons donc proposé une approche originale et pour nous, bien plus intéressante. Nous aurions pu toutefois décider d utiliser une machine avec Windows, et une autre avec Linux, mais nous avons préféré dédier nos tests à 2 O.S. Linux pour également montrer comment les choses peuvent tout aussi bien être différentes sur 2 machines équipées d un noyau à priori semblable. Nous avons eu au final beaucoup de plaisir à mettre en oeuvre ce laboratoire et nous sommes très satisfaits de nos résultats. De plus, ce que nous avons appris a été très bénéfique et a changé notre vision de voir les choses dans le domaine de la programmation concurrente. Définition dans le fichier rapport.txt.

Index ASM_BARRIERE cours.c, 6 dekker.c, 10 peterson.c, 15 cours cours.c, 6 cours.h, 7 cours.c, 5 ASM_BARRIERE, 6 cours, 6 cours.h, 7 cours, 7 peterson_finsectioncritique, 15 peterson.h, 16 peterson, 16 peterson_debutsectioncritique peterson.c, 15 peterson_finsectioncritique peterson.c, 15 psleep.h, 17 rapport.txt, 18 dekker dekker.c, 10 dekker.h, 11 dekker.c, 9 ASM_BARRIERE, 10 dekker, 10 dekker_debut_section_critique, 10 dekker_fin_section_critique, 10 NOMBRE_ITERATIONS, 10 dekker.h, 11 dekker, 11 dekker_debut_section_critique dekker.c, 10 dekker_fin_section_critique dekker.c, 10 labo2.c, 12 main, 13 main labo2.c, 13 NOMBRE_ITERATIONS dekker.c, 10 peterson peterson.c, 15 peterson.h, 16 peterson.c, 14 ASM_BARRIERE, 15 peterson, 15 peterson_debutsectioncritique, 15