Le dimanche 07 avril 2019, Odile a écrit :
> Merci pour l'info je ne connaissais pas. La seule raison pour laquelle
> j'envisageais du multi thread est à cause de l'envoi de messages sur
> l'arduino et l'attente d'un acknowledgment. IL me semble qu'il y a là
> matière à mettre 2 threads séparés non?
Il n'y a aucun souci à utiliser les threads, en particulier lors des
accès hardware. J'ai l'impression que beaucoup les décrient car ils ne
savent pas les utiliser, ou les utilisent à mauvais escient.
Dans ton cas, tu peux soit utiliser un thread dédié à la communication
avec l'Arduino, et avoir un mécanisme de communication entre ce thread et
le thread principal pour savoir quand c'est fini, soit faire du polling
depuis le thread principal, c'est à dire venir interroger à intervalle
régulier l'Arduino pour savoir s'il a fini, sans rester bloquer.
Ce qui ne faut surtout pas faire, et c'est pourtant ce que font beaucoup
de gens, et se cassent la gueule à cause de ça, c'est accéder à des
ressources communes depuis plusieurs threads. Ou alors, il faut utiliser
les mécanismes de synchronisation pour éviter les accès concurrents. Dans
tous les cas, il faut être rigoureux.
Splitter du code en thread peut être intéressant, car en Python, c'est
très simple de passer des threads aux sous-process. Dans ce dernier cas,
plus de souci de GIL, et ça permet d'exploiter les architectures
multi-coeurs. C'est ce que j'ai fait pour mon hexapode, justement, et en
un clin d'oeil, j'ai pu faire en sorte que le thread de pilotage des
servos tourne sur son propre coeur, pour aller plus vite, et lui faire
faire plus de choses, sans pénaliser le reste du code (les calculs trigo
prennent eux aussi des ressources).
--
Frédéric
