Dans les exemples du premier article de La Saga Blink, l’auteur mettait en avant l’intérêt de pouvoir se sortir de la boucle de clignotement d’une LED en proposant une ‘combine’ non bloquante de contrôle des caractères. Une solution qui peut paraître satisfaisante, mais l’est-elle réellement ? …

Bien que parfaitement fonctionnels, de nombreux exemples proposés souffrent d’une même anomalie que l’on ne peut ignorer du fait qu’elle remet en cause l’usage même de ces exemples dans d’autres programmes. Voyons donc pourquoi et comment faire autrement.

Exemple de surconsommation critique de ressource.

Pour l’exemple, j’utiliserai le cas du code Blink81. Pourquoi celui-là ? Déjà parce qu’il en faut un de concret. Ensuite parce que ce code est écrit en C sans GUI et utilise la librairie WinringPi. Parmi tous les exemples de l’article cité, c’est théoriquement celui qui devait s’avérer être le plus ‘économique’ et performant. Ceci dit, vous trouverez exactement la même anomalie dans la plupart des autres exemples similaires du même article, qu’ils soient écrit en C ou en Python.

J’ai donc téléchargé les sources et j’ai procédé à la compilation, conformément aux recommandations de l’auteur. Le programme compile sans problème et fait exactement ce qu’on attend de lui, à savoir, ‘blinker‘ une LED à une fréquence de ~1Hz.

Vu que cela fonctionne, Intéressons-nous maintenant à l’incidence de ce programme sur le système en utilisant simplement la commande ‘top’. Celle-ci indique en entête les ressources globales utilisées et celles disponibles puis la liste des processus les plus gourmands depuis le dernier rafraichissement

Ce que l’on constate immédiatement, c’est que le processus Blink81 occupe le haut du pavé avec 100% d’usage CPU. On peut admettre que le Pi (ici un Pi3) n’est pas un supercalculateur ni même un ordinateur de bureau, mais une telle dépense  juste pour faire clignoter une LED à une fréquence de 1 Hz, cela indique clairement  problème.

Limiter l’occupation dans les boucles infinies.

Les problèmes, Il ne suffit pas de le remarquer, faut-il encore en identifier les causes et les corriger. Ici, inutile de commenter tout le code, le problème se trouve dans la boucle for( ;;) et plus globalement dans la conception globale du programme lui-même. Si vous regardez cette boucle, elle contrôle les ‘éventuelles’ lettres saisies au clavier. Ensuite elle regarde si ‘éventuellement’ le temps d’état de changement est atteint, auquel cas, elle modifie cet état, puis recommence. Tout ceci ne représente tout au plus que quelques dizaines d’instructions banales, qu’un programme en C est normalement capable de traiter à la vitesse de la lumière sans broncher …

…Et c’est bien là le problème. Ces dizaines d’instructions sont ici exécutées, des milliers et des milliers de fois, pour finalement ne rien faire. En fait, cette boucle tourne aussi vite qu’elle peut jusqu’à consommer l’intégralité des ressources CPU qui lui sont allouées (et ça tourne vite le C, même sur un Pi rikiki …). Ajoutons à cela le fait que la fonction kbhit() mine de façon conséquente le rapport cyclique du signal et fatalement aussi sa fréquence.

Pour ceux qui ont chargé cet exemple je vous fais une suggestion toute simple pour estimer la quantité astronomique d’instructions inutiles qui sont exécutées. Ajoutez juste la ligne usleep(1000); dans la partie systématique de la boucle et constatez par vous-même le résultat avec la commande top.

Voilà ce que j’obtiens chez moi sur le Pi3:

Édifiant non ? En fait on a juste dit à la boucle de se reposer 1 seule petite milliseconde à chaque tour. Pensez donc à laisser reposer vos boucles, surtout si celles-ci n’incluent pas d’instructions bloquantes

Le problème, c’est que cette petite temporisation n’est forcément pas que bénéfique. La durée de pulsation et le rapport cyclique n’étaient déjà pas terrible à cause du nombre d’instructions exécutées entre chaque changement d’état et forcément ce ‘débogage’ est un peu comme un pansement sur une jambe de bois qui ne fait que masquer le véritable mal. Tant que l’on veut se contenter de ‘blinker’ une LED, ça peut le faire, mais si on a besoin d’un signal un peu plus précis et surtout la possibilité de faire autre chose dans le programme ou encore d’utiliser la méthode dans un autre, ça ne le fera jamais, et pour cause. Si l’appel kbhit() est non bloquant, la boucle globale l’est. Si vous voulez faire autre chose de plus avec votre programme, vous serez obligé de l’inclure dans cette boucle, ce qui aura pour effet d’accentuer le problème.

Un exemple de thread simple pour se libérer des boucles dans les boucles.

Comme l’idée n’était pas de critiquer bêtement une méthode mais bien de proposer une alternative qui puisse répondre plus favorablement aux cas plus exigeants d’un simple blink, je vous soumets ce tout petit programme sans prétention. Il fait exactement la même chose que Blink81 et que ses homologues en Python. Je profite de l’occasion pour ajouter une librairie qui permet d’accéder aux GPIO et qui n’avait pas été utilisée dans le tuto précédent. Il s’agit de la librairie bcm2835. On ne voit pas trop de gens l’utiliser sur les forums. Je pense que c’est parce qu’elle ne semble pas aussi ‘avenante’ que la célèbre WiringPi. Il faut la compiler pour l’installer ce qui la rend par conséquent moins populaire et c’est bien dommage, parce qu’à ma connaissance, c’est de très loin la plus performante. Pour la programmation, j’ai utilisé aussi un langage différent, à savoir le C++. Une fois la lib2835 installée, La compilation se fait donc par la ligne suivante:
g++ -o monblink main.cpp –Wall –lpthread –lbcm2835
Notez le g++ au lieu de gcc utilisé pour Blink81. Pour le coté hardware, c’est la même GPIO que pour Blink81 (la broche 16 du connecteur, GPIO23). Maintenant, compilez, exécutez (pas besoin de sudo pour ca avec cette lib), et comparez.

Vous pouvez chercher monblink dans le ‘top’ mais vous avez peu de chance de le voir dans la liste et s’il advenait qu’il y apparaisse, ce serait très ponctuellement et avec une valeur de consommation CPU infime. Pourquoi ? Hé bien tout simplement parce que ce programme ne fait rien. Enfin, disons qu’il ne fait surtout rien d’inutile. Si on veut apercevoir le process dans top, on peut essayer. Il suffit par exemple de passer la valeur DELAIS à 1 au lieu de 500. Malgré cela, le procès consommera toujours bien moins que l’exemple Blink81 ‘débogué’ et pourtant avec une vitesse de blink 500 fois plus rapide.

La subtilité de ce programme tient dans une seule notion, celle des threads. Il faut considérer les threads un peu comme des portions de programmes qui tournent à l’intérieur du programme principal. Pour blinker une LED, il n’y a pas besoin de 50 instructions qui s’exécutent des milliers de fois pour ne rien faire. Fondamentalement 2 ou 3 suffisent pour peu qu’elles soient utilisées exclusivement quand il y en a vraiment besoin.

J’ai la conviction qu’un code aussi simple est suffisamment explicite pour se passer de commentaire mais je vais quand apporter quelques précisions.

La procédure ‘blinkLed()’
– La variable booléenne b représente la valeur ‘on’ ou ‘off’ que l’on va utiliser pour initialiser l’état de la led.
– En début de boucle, bcm2835_gpio_write écrit la valeur b sur la pin gpio LED
– La ligne bcm2835_delay met la boucle en pause pour temps DELAIS (milliseconde).
– Au réveil, la valeur de b est inversée et la boucle retourne à son début.

Le ‘main()’
– bcm2835_init initialise la librairie et en cas d’échec le programme s’arrête en retournant une erreur.
– bcm2835_gpio_fsel initialise la pin LED en sortie
– Ensuite pthread_create. C’est la toute la subtilité du programme. Cette ligne va stocker la procédure blinkLed() dans un espace réservé et cette procédure va s’exécuter. blinkLed() est désormais un thread secondaire qui s’exécute en arrière-plan du thread principal (main()) qui lui peu continuer sa route.
– La boucle while(s != q)… attend qu’une chaine de caractères soit validée au clavier. Si cette chaine est ‘q’, le programme poursuit sa route, sinon il attend.
– pthread_cancel, comme son nom l’indique donne l’ordre d’arrêter le thread secondaire (donc la procédure blinkLed()) et la ligne pthread_join attend que cet arrêt soit effectif avant de poursuivre.
– Comme on ne sait pas à quel moment de son exécution le thread s’est arrêté, on force l’extinction de la LED puis on libère les ressources occupées par bcm_2835.

On aurait très bien pu utiliser une variable pour conditionner la sortie de la boucle de blinkLed et ainsi se passer de pthread_cancel, mais ici cela n’aurait fait que compliquer l’exemple et ne nous aurait rien apporté de plus. Par contre cela aurait été indispensable notamment si il y avait eu d’autres instructions a exécuter dans blinkLed() après la sortie de la boucle. En effet, pthread_cancel arrête le thread a l’endroit ou il se trouve, ce qui n’est pas systématiquement une bonne chose.

Pour ceux qui désirent ‘tester’ sans avoir à installer la libraire bcm2835, rien de plus simple. Voici une variante qui utilise cette fois ci la libraire WiringPi et a compiler comme suit :
g++ -o monblink main.cpp –Wall –lpthread –lwiringPi

Les threads dans les différents langages.

Si vous regardez ce code, vous pouvez être amené à penser qu’il n’y a pas beaucoup de différence entre C et C++. Dans ce cas de figure, effectivement et c’est parfaitement volontaire. En modifiant uniquement quelques noms de fonction, ce programme pourrait tout à fait être compilé en C. Mais ne vous y tromper pas, en réalité, ces 2 langages sont très différents l’un de l’autre.
Concernant les développeurs Python, sachez que le langage possède aussi une notion de thread. A mon sens, c’est un des langages parmi les plus pauvres dans ce domaine, mais ils permettent déjà beaucoup et cela vaut vraiment la peine de s’y intéresser. Sinon, parmi les langages managés disponibles facilement sur le Pi, Java et C# sont très performants pour gérer du multithread. Connaissant bien ces 2 langages sur les plateformes win, je dirais qu’à aujourd’hui, C# est de très loin le plus évolué pour ça, mais n’ayant pas suffisamment de recul avec le portage Mono sous linux, je ne pourrais pas l’affirmer pour le Pi (et ce n’est qu’un avis personnel).

Conclusion.

J’avais été surpris de voir des commentaires quasi unanimes qui pensaient que les threads étaient forcément trop compliqué voir même ‘hors sujet’ pour faire simplement clignoter une LED. Pour les débutants, il faut faire simple même si c’est au détriment d’un peu de performance me disait-on. Sur ce dernier point je suis tout à fait d’accord et je vous laisse juger de la simplicité de cet exemple ‘threadé’ comparé aux ‘usines à gaz’ cités précédemment. A mon sens, le clignotement d’une LED dans un programme justifie pleinement l’usage d’un thread et je dirais même que c’est le type de cas qui démontrera en premier que c’est quasi indispensable.

J’espère que ce petit article aura contribué à chasser le méchant fantôme des threads. En tout cas, il aura démontré que l’on peut très bien faire des programmes lourds, compliqués et même bogués si on à trop peur de les utiliser. Après, il faut être conscient que le multithreading est une notion extrêmement puissante au sein d’un programme. Il ne suffit pas de démarrer des tas de thread dans tous les sens, il faut aussi les contrôler et bien réfléchir à l’effet de chacun sur les autres. Il existe des tas de choses pour s’accommoder des threads dans tous les cas d’usage. Notamment les notions de verrou et de de priorité, mais là, je vous l’accorde, cela dépasse le cadre du cas d’usage d’un simple ‘blinking’ qui n’a pas besoin de tout ça.

Références.

La librairies BCM2835
Un peu d’aide en Français.
La commande top sous linux
Autres exemples pthread