Discussion :

[cosmoff]

bonjour à tous

voila j'ai quelques questions sur les threads et multiprocessing car j'ai du mal a faire la différence entre les deux et vous allez surement m'éclairer.

deja faut il plusieurs processeurs pour utiliser les threads, car chaque processeur éxécuterait un programme non ?pareil pour le multiprocessing?

a ce que j'ai pu voir pour les threads ca permet de créer plusieurs fonctions qui peuvent fonctionner en meme temps au lieu de fonction l'une apres l'autre ou alors c'est ce que fait le multiprocessing?

je veux realiser un robot qui est capable de se repérer dans un plan via des ultrasons et donc j'aimerais faire une boucle ou ce programme est sans cesse éxécuté pour voir si les distances entre mes Ultrasons - obstacles sont assez grande, et si jamais l'obstacle est trop proche bah je met un flag a une variable
qui sera lu par un autre programme qui li cette variable mais sans interagir avec le programme des ultrasons, a ce que j'ai pu voir les threads font tres bien ca, pouvez vous me le confirmer ?

merci d'avance pour vos reponses

[Sve@r]

Bonjour

Beaucoup de questions. Essayons de répondre
1) non, il ne faut pas plusieurs processeurs pour faire du multiprocessing ou du multithread. Je pense même que même si t'as plusieurs processeurs, comme t'as qu'un seul programme qui tourne il tourne sur un seul processeur (et un autre programme qui n'a rien à voir tournera sur un autre).
2) le multithread comme le multiprocessing permettent de faire tous deux de la programmation parallèle (effectivement on fait tourner plusieurs fonctions en même temps). En fait, les fonctions sont exécutées une après l'autre mais petit bout par petit bout (c'est géré par l'ordonnanceur de taches). Mais ça va tellement vite que t'as l'impression qu'elles tournent en même temps. C'est d'ailleurs pareil pour tous les programmes de ton ordi.
3) la différence entre les deux vient de l'historique. Le multiprocessing a été inventé dans le monde Unix, qui s'est ensuite porté sur Linux. Le multithread a été inventé dans le monde Windows. Mais le principe général des deux est exactement le même: faire tourner plusieurs trucs en même temps. Ensuite viennent les détails qui les diffèrent. Dans le monde Unix, priorité a été donné à la sécurité. Tout est fermé par défaut et on ouvre ce dont on a besoin pour travailler. Le multiprocessing répond donc à cette règle. En multiprocessing, chaque processus est totalement isolé des autres y compris pour les zones mémoires (qui restent individuelles) et c'est à toi d'établir des ponts de communication entre chacun si tu veux leur faire échanger des données.
Dans le monde Windows, priorité a été donné à la large diffusion. Faut que tout puisse fonctionner immédiatement chez tout le monde (intégrer un nouveau driver, faire qu'un nouveau code puisse facilement utiliser des api déjà existantes). C'est aussi ce qui explique la prolifération des virus qui ne sont retenus par rien. Un peu comme si on construisait une maison sans porte puis qu'on décide de boucher les ouvertures selon les besoins. Le multithread a suivi ce principe et en multithread, tous les différents thread ont tous accès à la mémoire globale du programme qui peut être modifiée par l'un ou par l'autre sans souci.

Concernant ton robot tu parles de deux programmes différents, le premier qui envoie des ultrasons et le second qui regarde la variable. Dans ce cas, ni les thread ni le multiprocessing ne peuvent t'aider car l'un comme l'autre ne peuvent être mis en oeuvre que dans un seul et même programme. Un programme unique peut donc mettre en oeuvre du multithread ou du multiprocessing ; où ensuite chaque thread ou processus ira ensuite s'occuper de sa propre tache individuelle ; mais deux programmes distincts ne peuvent pas utiliser de thread ou processus commun. Là ce que tu cherches c'est de la communication cette fois inter programme qui se fait par le biais d'outils comme fichiers disques, socket, pipes, files de messages, mémoire partagée (et ces outils peuvent aussi être utilisée pour faire communiquer plusieurs processus d'un même programme dans le cas du multiprocessing avec ses différents processus isolés les uns des autres)...

PS: ce sujet n'a rien à voir avec Python...

[cosmoff]

PS: ce sujet n'a rien à voir avec Python...

je fais mon programme en python donc vu que les thread sont disponibles sur python j'ai donc posté ici.

merci beaucoup pour ton explication tres complete.

[wiztricks]

Salut,

je veux realiser un robot qui est capable de se repérer dans un plan via des ultrasons et donc j'aimerais faire une boucle ou ce programme est sans cesse éxécuté pour voir si les distances entre mes Ultrasons - obstacles sont assez grande, et si jamais l'obstacle est trop proche bah je met un flag a une variable
qui sera lu par un autre programme qui li cette variable mais sans interagir avec le programme des ultrasons, a ce que j'ai pu voir les threads font tres bien ca, pouvez vous me le confirmer ?

"threads","multiprocessing" ou mieux concurrent.futures sont fait pour çà.
Par contre, comme l'a noté Sve@r, ils permettent de paralléliser les fonctions d'un même programme et non de plusieurs programmes.
Dans ce cas, on peut utiliser le module subprocess mais échanger des informations entre "programmes" devient plus compliqué.

Mais peut être faudrait-il préciser ce que vous entendez par "programme"?

- W