Version imprimable
Bonjour,
J'aimerai connaître très précisément les changements lorsqu'un nouveau thread démarre, après par exemple l'appel de la fonction "CreateThread".
La question semble sans doute un peu vague, mais ce sont mes connaissances sur le sujet qui le sont aussi. D'où une question vague.
Merci par avance ;)
Effectivement, la question est vague et donc ma réponse sera générale.
Déjà, tu peux regarder sur Wiki pour de l'info générale : http://fr.wikipedia.org/wiki/Processus_l%C3%A9ger
Pour définir un thread, il fdaut d'abord définir un processus. Le lancement d'un programme (double clic sur un exe par exemple) correspond à la création d'un processus. Un processus, c'est de l'espace mémoire adressable par ce processus (le tas, la pile, les variables globales) et un thread principal (ou unité d'exécution) dont le point d'entrée en C et C++ correspond à la fonction main() ou WinMain() pour les programmes graphiques Windows. Pour info, il y a beaucoup de choses de choses qui sont faites par le loader de processus avant d'arriver à la fonction main() ou WinMain().
Une fois que ton programme se déroule, tu peut créer autant de thread que tu veux (aux ressources près de la machine quand même) avec entre autre la fonction CreateThread(). Cette fonction va définir une autre unité d'exécution qui va démarrer à partir du point d'entrée (c'est une fonction) que tu spécifies. Ce thread se termine lorsqu'il quitte la fonction définie comme point d'entrée du thread.
Ensuite, le système va donner du temps CPU à chacun des threads. Les 2 thread s'exécuteront simultanément et pourront faire 2 choses différentes en parallèle. C'est ce qui va donner une certaine illusion de multi tâches. Un thread pouura gérer l'interface Homme - Machine alors que k'autre thread pourra charger un fichier volumineux et que le 3eme thread pourra gérer tous les accès réseau.
Il faut bien voir que tout l'espace mémoire créé et accessible par le thread principal est aussi accessible par les autres threads. C'est la grosse différence entre thread et processus, 2 processus ne partagent pas leur espace mémoire alors que 2 thread d'un même processus ont le même espace mémoire.
Merci pour cette explication claire.
Néanmoins, j'aimerai aller plus loin dans l'étude.
Tu dis qu'à un processus correspond une pile.
Hors il me semblait avoir compris durant mes recherches que une pile correspond à un thread.Citation:
c'est de l'espace mémoire adressable par ce processus (le tas, la pile, les variables globales) et un thread principal (ou unité d'exécution)
Donc il y aurait autant de piles que de thread non?
Sinon je ne vois pas comment s'organise la gestion des instructions si plusieurs thread se mélangent dans la même pile.
Deuxième question qui me vient à l'esprit, comment la mémoire utilisé par le nouveau thread ( pour les variables locales ) va être gérée? L'os s'occupe-t-il tout seul d'allouer une nouvelle section dans la mémoire du processus en cours?
Pour préciser ma question voici où je bloque :
Lorsqu'on lance notre exécutable, le loader lit l'en tête du fichier. Il alloue un espace mémoire à noter application, puis il charge dans cette espace, les différentes section qu'il aura trouvé dans notre en tête ( .text, .data, ... ).
Il va également charger les différentes Dlls contenant les fonctions importées par l'application.
Ensuite si dans notre application on invoque un nouveau thread, qu'est ce qui se produit exactement? Va-t-il y avoir une nouvelle section chargée?
Oui, tu as raison, ce détail m'avait échappé. La création d'un thread créé aussi une pile pour ce thread.Citation:
Envoyé par klakman
Non, dans le cas de plusieurs thread, il y a partage des sections de données, elles ne sont pas rechargées. C'est la grosse différence entre thread et processus.Citation:
Envoyé par klakman
Cela as bien sur des avantages et des inconvénients :
- Le context switching des thread est plus rapide que pour des processus (il y a moins de choses à changer).
- La programmation multi thread est plus délicate que la programmation multi processus (il faut protéger les données lorsque 2 thread peuvent avoir un accès concurrent sur ces données)
Merci pour cette info.
Une dernière chose qui m'échappe pour le moment.
Tu parles bien de sémaphores?Citation:
il faut protéger les données lorsque 2 thread peuvent avoir un accès concurrent sur ces données
Qui permet ( dîtes moi si je me trompe ) de bloquer tout autres threads nécessitant un accès à une zone mémoire, pendant qu'un thread exécute ses actions dessus.
Si non, à quel type de protection fais-tu allusion? Peut-il y avoir des protections qui réservent un espace mémoire à un unique thread?
Chaque thread a sa propre pile, son propre contexte d'exécution (ce qui inclus l'affinité processeur, la priorité et le TID), et enfin son propre TLS (Thread Local Storage).Citation:
Envoyé par ram-0000
Tout le reste est commun à tous les threads du même processus, notamment le mapping mémoire, les handles sur ressources, le PID, etc.
Attention quand même : une DLL déjà en mémoire et attachée au processus s'attache également au thread lors du lancement de ce dernier (cf. fonction "DllMain").Citation:
Envoyé par ram-0000
La DLL n'est bien sûr pas rechargée, mais elle peut être initialisée plus ou moins automatiquement lors de la création d'un thread.
C'est notamment pour cette raison que l'on conseille de créer tous les threads requis en début de programme, puis de les suspendre pour les faire bosser en fonction des besoins.
De plus, à titre d'information générale : Windows est très efficace sur la gestion des threads, et bien moins sur la gestion des processus. C'est exactement l'inverse pour les systèmes Unix, notamment Linux.
Sémaphores, mutex, barrières, etc. De manière générale, ce sont des "objets de synchronisation".Citation:
Envoyé par klakman
De façon "inviolable", non. D'ailleurs, même une zone protégée par un mutex peut être accédée de façon sale (sans prendre le mutex, donc), et un thread peut donc y faire n'importe quoi. Les zones ne sont protégées que parce que le développeur le veut bien, et non pas parce que c'est impossible autrement.Citation:
Envoyé par klakman
Les seules données strictement spécifiques à un thread, et inaccessibles aux autres threads, c'est le TLS.
Merci pour ces précisions.
Seulement ça fait un petit moment que je cherche des infos sur le TLS des threads et j'ai pas trouvé d'info sur le faite que c'était inaccessible par les autres threads.
Voici ce que j'ai trouvé entre autre :
ici : http://www.open-std.org/jtc1/sc22/wg...006/n1966.htmlCitation:
The address of a thread variable may be freely used during the variable's lifetime by any thread in the program.
et la documentation microsoft :
ici : http://msdn.microsoft.com/en-us/libr...49(VS.85).aspxCitation:
With thread local storage (TLS), you can provide unique data for each thread that the process can access using a global index.
Je n'ai pas vu de mention spécifiant que les données spécifiées étaient inaccessible par un autre thread que l'utilisateur de cette donnée.
Maintenant peut être que c'est implicite et que je n'ai pas très bien compris le TLS?
Alors : le TLS, en très très très schématisé, c'est un tableau de pointeurs, dont la taille varie en fonction du système d'exploitation. Disons qu'il fait 64 entrées pour l'exemple.
Lorsqu'un thread, n'importe lequel, alloue un TLS, il récupère un indice dans ce tableau. Par exemple, 12, car les 11 premiers étaient déjà alloués.
Exactement au même moment, tous les threads du processus ont alors accès à leur propre TLS à l'indice 12. Le "12" est donc global au processus, il a été créé par un des threads du processus (le principal en général), et est lu par les autres (les threads secondaires). Bien entendu, comme ils ne font que lire, pas besoin de mutex.
Cependant, chaque thread a sa PROPRE valeur à l'adresse 12 en question. Si le thread A y met par exemple "0xDEADBEEF" et le thread B "0xCAFEBABE", alors le thread A n'a absolument aucun moyen de connaître la valeur contenue dans le TLS de B, et réciproquement. Toutefois, les deux threads partagent bien entendu le même indice, qui correspond en général à une donnée particulière.
A quoi servent les TLS, alors ? A rendre une fonction dans ton code totalement indépendante du thread qui l'exécute. Elle ira récupérer les données spécifiques du thread dans le TLS (à un indice particulier, global au processus donc), et grâce à cela, n'affectera QUE le thread courant. Si la fonction se fait interrompre par elle-même, au sein d'un autre thread, le TLS change et donc les données aussi, aucun conflit d'accès.
Il faut et il suffit de mettre les bonnes données dans le TLS. Habituellement, on crée une structure (plus ou moins complexe), contenant tout ce dont le thread peut avoir besoin, et on passe cette structure au thread à sa création qui va alors immédiatement en stocker l'adresse dans son TLS. Ainsi, toute fonction dépendante du contexte (pour obtenir une socket, par exemple, ou un handle sur un fichier de log, ou n'importe quoi d'autre !) peut obtenir les données propres du thread sans requérir de passage de paramètres explicites. Ces paramètres font alors partie de l'environnement du thread.
Pour la petite histoire, le système d'exploitation utilise par exemple le TLS pour stocker des données comme le "errno" (ou "GetLastError" sous Win32), de façon à ne pas polluer un thread donné avec les valeurs d'erreurs des autres threads.
Est-ce plus clair ?
Merci bien bien plus clair! ( Y a pas à dire je comprends mieux en francais :mouarf: )
Donc si j'ai bien compris, le TLS est un tableau qui stoque les infos particulière au thread en cours. Donc si on change de thread, le LPVOID de la case "12" ( pour reprendre ton exemple ) change pour pointer sur une nouvelle adresse?
Si oui, justement l'adresse sur laquelle le LPVOID pointe, on est d'accord qu'il s'agit du première octet de la donné? Mais où cette donnée est stoquée?
Elle peut être stoquée n'importe où ( ou presque ) dans la mémoire du processus? ( Au final comme une variable classique par exemple )
Une autre petite question, de 0 à 11 quelles types d'informations on a? des choses comme priorité du thread, ...?
C'est exactement ça.Citation:
Envoyé par klakman
Ou l'adresse de la structure, suivant comment tu veux l'interpréter.Citation:
Envoyé par klakman
Où tu veux, tant que tu peux en avoir l'adresse, on s'en fiche. Les autres threads n'y ont normalement pas accès, sauf à communiquer explicitement cette adresse à d'autres threads (ce que l'on ne fait bien sûr pas).Citation:
Envoyé par klakman
Pour ma part, dans la fonction principale du thread, je recopie cette structure en tant que variable locale, puis j'initialise le TLS avec. Ainsi, tant que le thread est vivant, la donnée existe, et dès qu'on sort de la fonction (=fin du thread), elle disparait en même temps que le thread lui-même.
Tu n'as en fait pas à le savoir : ce sont d'autres routines qui les utilisent, pas les tiennes, c'est tout ce que tu as à savoir. Manipuler ces données sans savoir exactement ce qu'elles contiennent peut crasher au mieux ton thread, au pire ton système.Citation:
Envoyé par klakman
Tu ne dois utiliser que tes slots de TLS, que tu as alloués toi-même. Et jamais les autres.
Un autre exemple typique d'utilisation d'un TLS, c'est une DLL complexe qui se sert dudit TLS pour stocker les informations propres au thread, passés en général via une fonction de type "Register".
Merci pour tout, je pense avoir compris les bases du multi threading, et je vais pouvoir progresser seul avec un peu de code maintenant.