IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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++ Discussion :

C'est quoi un "thread" ?


Sujet :

C++

  1. #21
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    Septembre 2007
    Messages
    7 472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 472
    Par défaut
    Citation Envoyé par buggen25 Voir le message
    Ben, qu'on on compile on utilise bien le processeur ?
    Et, quand tu compiles, tu utilises forcément des threads ? Je suis sûr que l'une de tes deux compils n'était pas parallélisée !

    Non, franchement, sans méchanceté, ce n'est même pas de la guerre de clochers, ici. Tu as fait l'effort de lancer des compilations sur plusieurs systèmes et malgré ça, tu vas passer pour un âne devant n'importe quel employeur, si tu tires ce genre de conclusions.

  2. #22
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Par défaut
    Citation Envoyé par buggen25 Voir le message
    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
    Pour l'un de mes programmes, j'ai le même code sous Windows et sous Linux. Le code sous Windows est 4 fois plus lent que celui sous Linux.

  3. #23
    Membre très actif
    Avatar de buggen25
    Ingénieur développement logiciels
    Inscrit en
    Août 2008
    Messages
    554
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Août 2008
    Messages : 554
    Par défaut
    Citation Envoyé par r0d Voir le message
    -> 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.
    C'est vrai que c'est vraiment approximatif, désolé pour ça !
    Bon la première fois que j'ai utilisé un ordinateur remonte à il ya 3 ans ce qui est relativement cours

    Concérnant le compilation de Qt sous linux, ben j'ai attendu 5 heures pour que Qt me gènère les fichiers "executables". je suis resté 5 heurs à regarder les instructions défiler.

    Concérnant les conditions de compilation :
    Sur windows:
    Le compilateur est MinGW c'est du GNU )
    sur cmd je tappe configure, pui make
    Sur linux , je rentre dans le dossier comportant les sources de qt
    je déclache l'execution de fichier sh "configure"
    ensuite je tappe;
    gmake
    puis j'attend 5 heures

  4. #24
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Par défaut
    C'est pas du tout le même compilateur que tu utilises, pas forcément les mêmes options de compilation (peut-être plus de bibliothèques additionnelles sous Linux), mais surtout gcc.
    GCC 4.x est assez lent, mais ça vaut la peine par la suite (cf mon message précédent).

  5. #25
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    Septembre 2007
    Messages
    7 472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 472
    Par défaut
    Citation Envoyé par buggen25 Voir le message
    sur cmd je tappe configure, pui make
    je déclache l'execution de fichier sh "configure"ensuite je tappe; gmake
    Il est fort probable que tu n'aies pas tout compilé (ni d'un côté, ni de l'autre, d'ailleurs). ./configure sert notamment à cela : sélectionner les composants qui doivent être construits ou non. Et ceux-ci sont choisis en fonction de ton environnement. Avec MinGW sous Windows, celui-ci devait être minimum, et la compilation t'a construit un truc en rapport.

    Ensuite, as-tu vérifié pendant la compilation que le compilateur sous Windows lançait bien des threads ou n'est-ce qu'une supposition ?

    Enfin, comme dit plus haut, il faut passer l'option -j à make pour lui demander de lancer plusieurs jobs à la fois (ce ne sont pas à proprement parler des threads, toutefois).

  6. #26
    Membre très actif
    Avatar de buggen25
    Ingénieur développement logiciels
    Inscrit en
    Août 2008
    Messages
    554
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Août 2008
    Messages : 554
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Et, quand tu compiles, tu utilises forcément des threads ? Je suis sûr que l'une de tes deux compils n'était pas parallélisée !
    .
    J'ai jamais dit ça, j'ai meme pas pensé à ça !
    Citation Envoyé par Obsidian Voir le message
    Non, franchement, sans méchanceté, ce n'est même pas de la guerre de clochers, ici. Tu as fait l'effort de lancer des compilations sur plusieurs systèmes et malgré ça, tu vas passer pour un âne devant n'importe quel employeur, si tu tires ce genre de conclusions.
    Sans comentaires

  7. #27
    Membre très actif
    Avatar de buggen25
    Ingénieur développement logiciels
    Inscrit en
    Août 2008
    Messages
    554
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Août 2008
    Messages : 554
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Il est fort probable que tu n'aies pas tout compilé (ni d'un côté, ni de l'autre, d'ailleurs). ./configure sert notamment à cela : sélectionner les composants qui doivent être construits ou non. Et ceux-ci sont choisis en fonction de ton environnement. Avec MinGW sous Windows, celui-ci devait être minimum, et la compilation t'a construit un truc en rapport.
    ).
    Suis le lien http://www.developpez.net/forums/d57...e/#post3428127

    On va pas en faire toute un plat

  8. #28
    Expert confirmé

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    Février 2007
    Messages
    4 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2007
    Messages : 4 253
    Billets dans le blog
    3
    Par défaut
    De toute maniere, tous les OS marchent pareil, et je n'ai jamais vu de différence entre Linux et Windows de ce coté... A part, peut-être un accès plus facile sous Windows SDK à certaines fonctions (comme la sélection du CPU préféré pour le thread, la priorité d'execution, ...), mais je ne suis pas un fin connaisseur de tous les noyaux unix (et tous les unix ne sont pas égaux devant les threads).

    Quand on "lance" un programme, l'OS crée un "processus" (allocation mémoire, mapping mémoire virtuelle, chargement du code, handles d'entrée/sortie, ...), puis alloue un thread à ce processus (parfois appelé thread principal) pour executer le point d'entrée du processus ("main") qui dépend de l'OS.

    Ensuite, rien n'empêche ce thread principal de créer d'autres threads additionels au sein du même processus.

    Un thread regroupe un "état de fonctionnement CPU" (code actuel, pile, registres), le passage d'un thread à un autre "coute" cher (mais largement moins que sa création), mais permet entre autre, de continuer à faire des choses pendant qu'on attend autre chose (en général de l'I/O comme la lecture de fichier, le réseau, la carte graphique ou la carte son, ou bien attendre un évenement précis comme une heure donnée, une exception, etc...).

  9. #29
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    Juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2005
    Messages : 9 810
    Par défaut
    Un thread n'est pas un vrai processus, même sous Linux. On l'appelle processus léger, mais ce n'est pas un processus en tant que tel.

  10. #30
    Expert éminent
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 738
    Par défaut
    Citation Envoyé par Matthieu Brucher Voir le message
    Un thread n'est pas un vrai processus, même sous Linux. On l'appelle processus léger, mais ce n'est pas un processus en tant que tel.
    Côté compréhension, nombre de difficultés proviennent du fait qu'un "thread" est (ou pas) une entité gérée par l'ordonnanceur de "processus".
    Si les threads crées par/dans un processus sont gérées par l'ordonnanceur on parlera de correspondance 1x1 entre l'ensemble des objets gérés par l'ordonnanceur et l'ensemble des threads crées par les processus "actifs".

    Il existe un modèle de threading (plus léger) qui fait une correspondance MxN. Dans ce modèle, un process multi-threads dispose d'un ordonnanceur de premier niveau qui les multiplexe sur des threads de 2nd niveau (qui sont elles gérées par l'ordonnanceur de processus).

    A ma connaissance, Linux implémente, par défaut, un modèle 1x1.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  11. #31
    Membre éclairé Avatar de Vespasien
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    383
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 383
    Par défaut
    To the Linux Kernel, there is no concept of a thread. Linux implements all threads as standart processes. ... Instead, a thread is merely a process which shares certain resources. Each thread has a unique task_struct and appear to the kernel as a normal process (which shares resources, such more as an address space, with other processes)
    Linux Kernel Development Robert Love

    Il faut donc bien distinguer programme, processus et thread.

  12. #32
    Membre très actif
    Avatar de buggen25
    Ingénieur développement logiciels
    Inscrit en
    Août 2008
    Messages
    554
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Août 2008
    Messages : 554
    Par défaut
    Citation Envoyé par Vespasien Voir le message
    [I]To the Linux Kernel, there is no concept of a thread. Linux implements all threads as standart processes.
    Grossomodo, dans le noyau linux, le concpet de thread n'existe pas.

    Citation Envoyé par Vespasien Voir le message
    ... Instead, a thread is merely a process which shares certain resources. .
    Donc un thread selon linux est juste un processus qui partage quelques ressources

    Citation Envoyé par Vespasien Voir le message
    ... Il faut donc bien distinguer programme, processus et thread. .
    Abvious

  13. #33
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    Septembre 2007
    Messages
    7 472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 472
    Par défaut
    Citation Envoyé par wiztricks Voir le message
    Il existe un modèle de threading (plus léger) qui fait une correspondance MxN.
    Où M et N sont ?
    Je suppose que M=threads et N=processus.

    Dans ce modèle, un process multi-threads dispose d'un ordonnanceur de premier niveau qui les multiplexe sur des threads de 2nd niveau (qui sont elles gérées par l'ordonnanceur de processus).
    Ok, mais cet ordonnanceur de premier niveau, lui, fonctionne comment ? Sans être un expert, je me dis qu'il doit être soit coopératif, et dans ce cas, ça implique beaucoup de prérequis, soit préemptif comme les autres et dans ce cas, il fait double emploi avec l'ordonnanceur de processus normal (avec possibilité de concurrence).

    Si on affine l'ordonnanceur pour définir ce qui est partagé ou pas, et que l'on groupe les processus en session (comme ça se fait déjà sur Unix), il n'y plus rien qui distingue un processus d'un thread. Et il me semble que c'est bien ce que fait clone().

  14. #34
    Expert éminent
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 738
    Par défaut
    Envoyé par wiztricks Voir le message
    Il existe un modèle de threading (plus léger) qui fait une correspondance MxN.

    Citation Envoyé par Obsidian Voir le message
    Où M et N sont ?
    Je suppose que M=threads et N=processus.
    Plus précisément M threads de premier niveau qui peuvent être exécutée par N threads de second niveau (inutile d'avoir N grand devant le nombre de CPU par exemple).

    Ok, mais cet ordonnanceur de premier niveau, lui, fonctionne comment ? Sans être un expert, je me dis qu'il doit être soit coopératif, et dans ce cas, ça implique beaucoup de prérequis, soit préemptif comme les autres et dans ce cas, il fait double emploi avec l'ordonnanceur de processus normal (avec possibilité de concurrence).
    Par définition, la préemption sert à suspendre un thread actif suffisament longtemps alors que d'autres threads n'attendent que la libération d'un
    processeur pour s'exécuter.
    On peut donc laisser faire la préemption par l'ordonnanceur de second niveau.

    Si on affine l'ordonnanceur pour définir ce qui est partagé ou pas, et que l'on groupe les processus en session (comme ça se fait déjà sur Unix), il n'y plus rien qui distingue un processus d'un thread. Et il me semble que c'est bien ce que fait clone().
    Quelque soit le modèle de threading, un processus est définit par un espace d'adressage virtuel et l'ensemble des threads qui le partagent.

    Il y a quelques subtiles différences entre:
    • la création de la première thread impliquant celle au préalable de l'espace virtuel
    • l'ajout de thread à l'objet précédemment crée.

    Et le mélange systématique entre le "quoi" et les implémentations réalisées n'aide pas à faire la différence entre l'essentiel et le spécifique.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  15. #35
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Il me semble que sous Linux, l'implémentation du multithreading a changé:
    • Avant l'invention de la NPTL, les différents threads d'un processus étaient gérés par le processus lui-même, mais pour le Kernel il n'y avait toujours qu'un et un seul processus.
    • Depuis la NPTL, les threads sont des processus qui partagent une grosse part de ressources.

    Sous Windows NT, le kernel a toujours fait la différence entre processus et threads. Par contre, j'ignore ce qu'il en est pour les fibres.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  16. #36
    Expert éminent
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 738
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    Il me semble que sous Linux, l'implémentation du multithreading a changé:
    • Avant l'invention de la NPTL, les différents threads d'un processus étaient gérés par le processus lui-même, mais pour le Kernel il n'y avait toujours qu'un et un seul processus.
    • Depuis la NPTL, les threads sont des processus qui partagent une grosse part de ressources.

    Sous Windows NT, le kernel a toujours fait la différence entre processus et threads. Par contre, j'ignore ce qu'il en est pour les fibres.
    Si on garde la définition du multithreading comme étant "plusieurs fils ordonnançables indépendament" qui partagent le même espace d'adressage (virtuel), certaines libraries proposent un mécanisme parfois appelé "user level threads" dans lequel le noyau n'a aucune connaissance des "threads" crées dans/par le processus.
    => Plusieurs threads sont "multiplexées" dans un même processus.

    Cette approche à l'inconvénient de ne pouvoir profiter du nombre de processeurs dont pourrait disposer le système, ce qui limite les capacités de traitement à un seul CPU. Pour ce faire, il faut des entités ordonnançables par le noyau (des kernel threads).

    D'ou l'intérêt de différencier:
    - "users threads" : threads dont le noyau n'a pas connaissance et qui ne sont ordonnançables que par/depuis le process (ou plus précisément la librarie qui les gère).
    - "kernel threads" : threads ordonnançées par le noyau comme le sont des process mais qui partageant nombre de ressources (espace virtuel, mémoire résidente,...) sont un peu différent du processus classique.

    Sous Solaris, les "users threads" s'appellent simplement "threads" alors qu'elles sont nommées "fibers" sous Windows. De même les "kernel threads" sont désignées par LWP sous Solaris (LWP = Light Weight Process) et simplement threads sous Solaris.

    Windows semble ne proposer que des objets élémentaires fibers et threads, charge au développeur de créer l'ordonnanceur via "switchtofiber" - ce n'est pas des plus simple - alors que Solaris propose un ordonnanceur.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  17. #37
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Ce qu'il faut distinguer, c'est les threads noyau, aussi appelés LWP (lightweight processes) et les threads utilisateur.

    Les threads noyau sont plus coûteux, passent moins bien à l'échelle, mais ils sont capable d'être placés sur différents cœurs hyperthreadés, cœurs, processeurs, etc.
    Les threads utilisateur souffrent du fait que tout appel bloquant bloque tous les threads, ce qui peut se résoudre en remplaçant ces appels par l'équivalent non bloquant et en laissant l'ordonnanceur de threads utilisateur gérer le reste pour donner un comportement bloquant. Une alternative est aussi de déclencher un thread noyau pour ces cas-là.

    Linux ne fournit que des threads noyau.
    Libre à toi de faire au sein de ces threads noyau d'autres threads utilisateur, ce qu'on appelle du N:M.

  18. #38
    Membre éprouvé
    Profil pro
    Inscrit en
    Février 2007
    Messages
    217
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 217
    Par défaut
    C'est un sujet super interressant, je squatte !

    Quelles sont les (autres) différences notoires entre ce que permettent Windows, Linux et solaris?
    Par exemple les fibres (que vous m'avez fait découvrir - merci) sont elles disponibles sur ces trois plateformes? Les bacs à threads (traduction perso de thread pool), les conditions et tout ça ?...

  19. #39
    Membre confirmé
    Inscrit en
    Octobre 2006
    Messages
    90
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 90
    Par défaut
    euuuhhh merci à tous ...

  20. #40
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    102
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Septembre 2006
    Messages : 102
    Par défaut
    Citation Envoyé par khazna Voir le message
    Les bacs à threads (traduction perso de thread pool)
    C'est plutôt "la piscine chlorée de threads où nagent les enfants".

    Ca devient presque un cours de vocabulaire, non ?

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 3 PremièrePremière 123 DernièreDernière

Discussions similaires

  1. [vb.net] C'est quoi un Thread ???
    Par arnolem dans le forum Windows Forms
    Réponses: 3
    Dernier message: 28/11/2005, 10h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo