Hello les gens,
Qqn peut-il me dire ce qu'est un 'threads', et comment ça marche ?
Merci les pitchounettes ...
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C'est quoi un "thread" ?
Hello les gens,
Qqn peut-il me dire ce qu'est un 'threads', et comment ça marche ?
Merci les pitchounettes ...
Un « thread », littéralement, ça veut dire « fil ». Dans le principe, ça veut dire qu'il va y avoir deux instances en train d'interpréter le même programme au sein du même processus.Envoyé par Sakapatate
Imagine par exemple que tu fasses un programme qui gère une interface graphique et qui déclenche une action quand on clique sur un bouton. Fort bien, mais l'interface reste alors indisponible pendant toute la durée de l'action, jusqu'à ce que le processus finisse ce qu'il est en train de faire et puisse retourner à sa tâche de surveillance de l'interface.
S'il y a deux fils d'exécution en parallèle au sein du même environnement, il y en a un qui peut rester au guichet pendant que l'autre, en coulisse, fabrique les petits pains :-)
Un thread est une fonction qui s'éxecute en parallèle à ton programme.
c'est un camambert
Un thread c'est quoi?
c'est juste une fonction au sein de ton programme ( le processus qui s'affiche dans ton gestionnaire des taches win )
contrairement aux fonctions d'un programme dit je cite a processus unique
qui s'execute en sequence, la fonction d'un thread s'execute en parrellel avec d'autre threads ( en faite c'est plutot du pseudoparallelisme puisque le processeur bascule plus rapidement d'un thread vers un autre que d'un processus vers un autre ).
C'est tu veux voir les threads en execution ( si tu le sais pas encore )
il suffit d'aller vers le gestionnaire des taches dans le sous menu affichage, tu selectionne l'option poour afficher les colonnes, dans la fenetre modale tu choisi d'afficher les threads
Et quand tu n'utilises pas Windows, tu n'as pas le droit aux threads ? :-)
Bien sur que oui
Bonjour;
Meme sur linux il y'a des threads si on utilise unistd.h
puis on utilise fork(),join()...
Mais c'est mieux sur windows ;-)
Euh, tu confonds beaucoup de choses, là.
Peut-être, mais c'est mieux également si tu visites clone() d'abord ...Mais c'est mieux sur windows ;-)
c vrai ça
fork, join ou thread meme combat, ça part du meme principe, le parallelisme.
en plus j'ai rien contre linux, je suis entrain de quitter windows ;-)
il y'a une instruction qui s'appele clone(); ça se trouve ou ça, je suis curieux !
Le principe est peut-être le même, mais fork != thread. Un fork, c'est un new process qui hérite de son père tout le bazzare. Un thread, c'est le même process qui fait un "schisme". Quand tu fais un fork(), tu dupliques tous les threads du process.
Les threads sous windows ne sont pas POSIX (I believe...), mais contrôle avant de prendre au mot ce que je dis.
Un petit lien:
Code : Sélectionner tout - Visualiser dans une fenêtre à part http://gauss.ececs.uc.edu/Users/Franco/ForksThreads/forks.html
Pas le même combat du tout ! fork(), join() et autres, ça crée des nouvelles instances du programme, des nouveaux processus (qui apparaissent donc dans le gestionnaire des taches). Ces instances ne partagent pas de variables, pas de mémoire.
Deux threads au sein d'un même processus partagent leur mémoire, les variables, ...
Bonjour,
il y a bequcoup d'erreurs dans les réponses qui ont été données ici. Pour continuer sur la lancée de Matthieu, je vais essayer de remettre les choses au clair.
Faux. Il ne faut pas confondre thread (que l'on peut trouver dans la littérature sous le nom de processus léger) et processus. Dans le gestionnaire des tâches Windows, ce ne sont pas les threads qui apparaissent, ce sont les processus.
C'est vrai dans le cas d'une machine qui n'a qu'un processeur et un seul noyau. Dans le cas où l'on plusieurs processeurs (ou plusieurs noyaux) et que nos threads sont "bien programmés", les threads s'exécutent réellement en même temps, sur des processeurs (ou noyaux) différents.
Non, un thread s'exectue à l'intérieur du programme. Deux threads s'exécutent en parrallèle.
Comme il a été dit, rien à voir.
Affirmation péremptoire s'il en est. Je ne vois pas en quoi c'est mieux sous windows, j'aurais même tendance à dire l'inverse. Cela dit, je suis disposé à réviser mon jugement si de bons arguments sont avancés.
En fait, pour résumer:
* Au début, tu as le programme P, ou processus. Quand le programme se lance, il s'accapare un morceau de mémoire.
* Ce programme P va faire des actions (lire des fichiers, faire des calculs, afficher des trucs à l'écran, etc...). Pour chacune de ces actions (pour simplifier) il va faire appel au processeur.
* Si dans ce programme P tu veux faire 2 choses en même temps, tu vas avoir besoin de créer un ou plusieurs threads. L'exemple classique c'est une application avec une interface graphique. Tu va lancer un thread T1 qui gère l'interface graphique, ainsi ton programme (ou processus) qui gère les données ne sera pas emmerdé s'il y a des soucis avec ton interface graphique, et vice-versa. Dans cet exemple, nous avons un seul thread T1, qui gère l'interface graphique, et un programme (ou processus) qui gère les données. T1 utilise la mémoire de P (alors que si on a un autre programme P2, ce dernier ne partagera pas la mémoire de P). Dans P, si tu crée un autre thread T2, (exemple typique, effectuer une lecture continue sur une ressource (port serie, usb, ethernet, bdd, lecteur CD, etc.) ) il partagera la mémoire de P et de T1.
Voilà, j'espère que ça éclaire un peu
clone() est un appel spécifique à Linux. Il te permet de faire en quelque sorte un fork() paramétré, en précisant ce qui doit être partagé entre le processus père et son fils, et ce qui doit rester commun. À l'extrême, tout est dupliqué et cela réalise un fork() normal, à l'autre extrême, tout est partagé et la seule chose qui change est le PID.
Ça a effectivement l'air « bidouille » vu de l'extérieur parce que l'on voit les threads traîner dans le ps, alors qu'en fait, c'est un moyen très pratique de ne pas réinventer la roue, et de pouvoir continuer à utiliser les mêmes outils. Tu peux tuer un thread, le débugger à la volée avec gdb comme tu le ferais avec un processus ordinaire, etc.
De toutes façons, les threads sous UNIX sont généralement exploités au travers de bibliothèques comme pthreads ou linuxthreads.
https://computing.llnl.gov/tutorials/pthreads/
http://pauillac.inria.fr/~xleroy/linuxthreads/
http://pwet.fr/man/linux/appels_systemes/clone
bah maintenant avec boost::thread, moi c'est vite vu: comme de toutes façon j'utilise tout le temps boost, que les threads de boost sont très bien, que c'est du c++ (alors que la plupart des libs de threading c'est du C) et qu'ils sont multi-plateforme. Que demander de plus?
C'est vrai pour l'histoire du fork et du join, je me trompe, c'est lamentable
Concernant la confusion entre thread et processus, je voulait afficher les threads d'un processus avec le gestionnaire des taches :
ctrl+alt+del
selectionner onglet Processus
menu->affichage->selectionner les colonnes
Dans la boite de dialogue on coche la case Nombre de threads.
C'est ça que je voulait dire mais le message n'est pas passé
Concernant les autre système d'exploitations style linux, il faut avoir une tres tres bonne machine, je m'explique :
j'ai une machine avec 512 MO de ram un processeur AMD 1.7 G
Je compile qt4 sur windows, ça prend 2 heures
je compile qt4 sur mandriva 2007, ça dure 5 heures !!!!!
Ben le constat est simple linux à des probleme avec ses processus et ses threads
Çà c'est la meilleure
C'est pas parce qu'il y a une différence de temps de compilation que tu peux dire que Linux a des problèmes avec ses processus et ses threads
Ah ouais, quand même !
Essaie make -j4 déjà, quand tu fais une compilation.
Ben, qu'on on compile on utilise bien le processeur ?Çà c'est la meilleure
C'est pas parce qu'il y a une différence de temps de compilation que tu peux dire que Linux a des problèmes avec ses processus et ses threads
Pour info, j'ai utilisé le meme compilateur make sur mandriva, et minGW sur windows. On utilise les memes ressources, les memes compilateurs !
D'ou vient le problème ? c'est linux
Comment peux-tu dire que tu utilises les même ressources sous Windows et sous Linux?Ben, qu'on on compile on utilise bien le processeur ?
Pour info, j'ai utilisé le meme compilateur make sur mandriva, et minGW sur windows. On utilise les memes ressources, les memes compilateurs !
D'ou vient le problème ? c'est linux
Je ne possède qu'une machine
Je les ai installé sur la meme machine windows et linux ?
Au temps pour moi, c'est bien que tu disais dans ton post, j'avais mal compris.
Un peu de rigueur, que diantre. La seule conclusion que l'on peut tirer de ce test c'est: "dans les conditions dans lesquelles tu as effectué l'opération, qt4 compile plus vite sous windows que sous linux". Mais:
-> nous ne connaissons pas les conditions de ton test. La commande de compilation sous chacun des os par exemple, utilisation ou non de l'os pendant la compil, processus qui tournent, compilo utilisé, etc, etc...
-> une mauvaise gestion des thread peut être la raison effectivement, mais ça peut également en être des milliers d'autres. Pourquoi choisir celle-là? Si effectivement, qt4 compile plus vite sous windows que sous linux - ce qui reste à prouver, mais il faudrait faire de vrais tests - il y a de fortes chances pour que l'explication n'ait à peu près rien à voir avec la gestion des threads.
-> vu le nombre d'erreurs, d'approximations et de phrases péremptoires dans tes précédents posts, j'ai du mal à prendre réellement au sérieux tes récentes affirmations.
Répondre avec citation
Partager