Discussion :

[klakman]

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

[ram-0000]

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.

[klakman]

Merci pour cette explication claire.

Néanmoins, j'aimerai aller plus loin dans l'étude.

Tu dis qu'à un processus correspond une pile.

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)

Hors il me semblait avoir compris durant mes recherches que une pile correspond à un thread.

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?

[ram-0000]

Hors il me semblait avoir compris durant mes recherches que une pile correspond à un thread.

Donc il y aurait autant de piles que de thread non?

Oui, tu as raison, ce détail m'avait échappé. La création d'un thread créé aussi une pile pour ce thread.

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?

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.

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)

[klakman]

Merci pour cette info.

Une dernière chose qui m'échappe pour le moment.

il faut protéger les données lorsque 2 thread peuvent avoir un accès concurrent sur ces données

Tu parles bien de sémaphores?
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?

[Mac LAK]

Oui, tu as raison, ce détail m'avait échappé. La création d'un thread créé aussi une pile pour ce 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).
Tout le reste est commun à tous les threads du même processus, notamment le mapping mémoire, les handles sur ressources, le PID, etc.

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.

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").
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.

Tu parles bien de sémaphores?
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.

Sémaphores, mutex, barrières, etc. De manière générale, ce sont des "objets de synchronisation".

Peut-il y avoir des protections qui réservent un espace mémoire à un unique thread?

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.

Les seules données strictement spécifiques à un thread, et inaccessibles aux autres threads, c'est le TLS.