Multithread: débogguer des applications multithread (NPTL)

Encore une présentation d’un beau projet.

Celui ci est à l’attention des personnes qui font des applications multithreadées. Quiconque a déjà programmé des applications threadées ont duûes comprendre la difficulté de:
[] Débogguer (terrible le déboggeur avec 6 ou 7 threads concurents!)
[
] tracer correctement des fonctions

Tracer le des threads parallèle est long (par la quantité de code à ajouter) et pas forcément facile car il est bien connu que l’usage des printf a une fâcheuse tendance à modifier la dynamique des processus, donc de générer des bugs ou en masquer…
Bien entendu l’excellent projet LTT permet de faire ça… dans le monde kernel! Mais rien pour les programmeurs normaux du monde user…

Heureusement un joli projet vient à leur aide, PTT : POSIX Tools Trace. C’est non intrusif (donc ça ne change pas la dynamique des fonctions, comme les fameux printf mis ça et là dans le code…) très simple à mettre en oeuvre (on change une variable PATH lors de l’exécution)

Pour le projet n’est pas encore fini, mais il avance vite et permets déjà d’aider grandement les développeurs…

http://nptltracetool.sourceforge.net/
download:

C’est possible d’expliquer simplement - pour un non-développeur - ce qu’est le (multi)thread ? :stuck_out_tongue:

Le multithread permet de diviser un processus en sortes de sous-processus (des threads, ou fils d’exécution) se partageant les ressources du processus parent. Leurs exécutions étant indépendantes les unes des autres, ils peuvent s’exécuter en parallèle (si plusieurs processeurs sont disponibles).
Bien sûr, comme ils ont accès aux mêmes resscources, il faut prévoir des mécanismes qui leur permettent d’éviter de se “marcher dessus”.
Et il est difficile de savoir quel thread est en cours d’exécution sur un processeur a un instant donné.

C’est un peu comme les logiciels de téléchargement qui scindent un même téléchargement en petits morceaux???

Pas tout à fait.
Pour donner un exemple concret : dans un jeu temps réel multijoueur (Unreal par exemple), il faut que les joueurs puissent réfléchir, agir, etc. “à peu près” en même temps… Il y aura donc un thread par joueur.
Un problème classique d’accès concurrent, c’est si deux joueurs prennent le drapeau en même temps.
Pour un programme séquentiel classique, le raisonnement serait : vérifier que le drapeau n’est pas pris, puis le prendre. Mais en programmation multithread, entre la vérification et la prise, il a pu être pris par un autre joueur. Si le jeu est mal conçu, cela pourrait, au choix, planter le jeu, faire disparaître définitivement le drapeau, ou le dupliquer. Ce genre de bugs peut être assez difficile à détecter, car ils se produisent dans des cas très rares où les threads agissent en même temps sur les mêmes ressources.

Et quel est le lien entre ça et le NTPL ?

Ben la gestion des threads se fait avec une bibliothèque dédiée, en l’occurence NPTL [:syl2002]

Pour compléter ce que dit asbel, dans le cas du drapeau, on peut avoir un problème de ‘dynamique’ c’est à dire que l’insertion d’une fontion ‘print’ pour dire ou on en est va rajouter un nouveau délais entre la vérification et la prise effective du drapeau… Et donc il peut rajouter (ou masquer) un bug car l’autre joueur pourra prendre le drapeau pendant ce délais.

Sinon NTPL : Native POSIX Threads Library qui remplace l’ancienne bibliothèque linux threads.
C’est la nouvelle version de la bibliothque de threads linux. Une partie est faite dans le noyau, l’autre en monde utilisateur.