Bonjour
 
J'aurais une question sur les threads.  
 
Est-il exacte de dire que les threads partagent une même zone mémoire, qui est le tas et data (variables globales et statiques) ?
 
Par ailleurs, j'entends souvent aussi dire que les threads partagent le même espace d'adressage. Est-ce que espace d'addressage == tas ?
 
merci par avance!  
 

L'espace d'adressage est une notion de l'OS.  Elle désigne la mémoire qui est accessible et les adresses qui y correspondent.
 
Le tas et la pile désigne des notions du langage (et pour le tas il y a une notion differente en structure de donnee, pour la pile il y a une structure de donnee apparentee et souvent une notion du processeur encore plus apparentee).
 
L'espace d'adressage est commun entre deux threads, le tas aussi mais la pile non (mais les deux piles se retrouvent dans le meme espace d'adressage et dont peuvent etre modifiees par les deux threads, chaque thread a neanmoins sa pile et ne va pas toucher a celle de l'autre sauf si on lui passe un pointeur vers celle-ci -- ce qui est souvent une erreur et toujours fragile).

merci pour ta réponse.
 
Donc si j'ai bien compris, tout est dans l'espace d'adressage la pile et le tas compris.
 
Mais la pile n'est pas partagée par les thread, chacun ayant sa propre pile.
 
C'est ça ?
 
Dans ce cas, vaut-il mieux parler de mémoire partagée (car apparement ca pourrait préter à confusion) ou de segments mémoires partagés ?
 
merci

On peut partager de la memoire sans partager l'espace memoire.  L'espace memoire est un mapping adresse->emplacement memoire. Deux processus differents peuvent partager de la memoire sans que l'espace memoire soit le meme; la memoire partagee pouvant se retrouver a la meme adresse dans les deux espaces memoire ou a des adresses differentes).  Deux threads partagent leur espace memoire.

salut,
ok, alors d'après ce que je comprend l'espace mémoire est une sorte de look-up table, c'est ça ?

donc les threads partagent cette zone qui contient tout un tas d'adresses, mais les segments mémoires à proprement parler vers lesquels pointent ces adresses de l'espace mémoire peuvent être les mêmes ... ou pas...

j'ai bon ?

le seul truc qui devrait varier quand tu es du point de vue d'un thread ou d'un autre dans un même processus, ca devrait être le thread local storage.
 
L'addressage virtuel est géré par processus. C'est ce qui te permet notamment de partager tes pointeurs entre tes threads sans trop te poser de question alors que, bien évidemment, passer un pointeur à un autre processus n'a pas de sens.

Les threads partagent tout. Les piles sont naturellement differentes mais sont accessibles aux autres threads.

 
hello,
est ce que ce pointeur est partagé, même s'il est déclaré sur la pile...??
 
par exemple :
 

 
merci

houlà, tu pars de travers, là.
Quoi qu'il arrive, tes threads ont chacun une pile d'exécution, vu que ce sont précisément des fils d'exécution qui vont être différents. Le principe de pile devrait te faire réaliser que dans le code que tu as écrit, aucune de ces variables n'est prtagée, et pire encore, tu pourrais très bien avoir plusieurs instances de ton tableau et de ton pointeur pour un thread donné simplement si ce thread réentre dans ta fonction.
 
on va faire un exemple moche différent avec une statique moche et deux attentes actives moches, mais ca te donnera une idée :
 

 
En général, on n'utilisera pas ce genre de fonctionnement. Tout système de thread te permet, lors du lancement du thread, de passer des informations de contexte (souvent sous la forme d'un void*) et du coup, les données que ton thread devra manipuler et partager avec d'autres lui seront accessibles au travers de ce contexte.

 
a est une variable locale, elle n'est accessible sous ce nom que par la fonction (et si il y a un appel recursif, chaque appel a sa variable, c'est aussi vrai si il y a plusieurs appels en meme temps par des threads differentes: chaque appel a sa variable).
 
Tu peux passer un pointeur vers a a une autre thread, elle pourra alors acceder a a a travers ce pointeur, tant que la fonction sera en cours d'execution. C'est en general une mauvaise idee.

@theshockwave : je regarde ça pour le programme Merci, comment fait-on pour acceder à ce fameux contexte ?

ok, merci => donc pas vraiment accessible à moins de le vouloir explicitement

j'aurais une autre petite question sur les threads si ça ne te dérange pas trop

J'ai fait un petit programme multithread, c'est juste une boucle qui lance plusieurs threads qui affichent chacun la valeur d'un index d'un tableau. Le voici :

Dans la fonction printNum => est ce qu'on est obligé de faire un lock/unlock si on veut afficher la valeur de chaque index du tableau par chacun des threads ? Y'a til une autre solution ..? car du coup je vois pas trop l'intérêt de paralléliser ce genre de traitement avec des lock/unlock quasiement tout le temps ...
Merci par avance

Tes differentes threads modifient le meme objet, il faut les synchroniser.
 
Pour le crash, *threads+i signifie (*threads)+i et pas *(threads+i) qui est ce qu'il faudrait (et qui s'ecrit plus simplement threads[i]).

oups, désolé effectivement j'ai vu l'erreur pour thread+i, merci

hum, ok donc on est obligé de mettre du mutex ...

Pari ailleurs, dans la boucle quand on crée les threads, en fait ils ne se lancent pas tous vraiment au même moment non ?

sinon je suis toujours intéressé par cette histoire de contexte. J'en entend souvent parler mais je le vois jamais ... On peut y accéder quelque part ? C'est l'OS qui gère les contextes ?

uuupp'z...

Ce qu'il faut comprendre, c'est qu'un programme s'exécute dans une enveloppe qu'on appelle processus. Les adresses sont locales à ce processus (le processeur et l'OS faisant la conversion pour aller chercher les données dans la mémoire physique).
Il y a au moins un thread (c'est ce qui fait qu'il y a de la vie dans le processus) mais, lorsque tu en crée d'autres, ceux-ci s'exécutent dans le même processus, donc partagent le même espace mémoire

 
 
Pour les contextes, si ce sont ceux que je mentionnais, c'est pas "géré" par l'OS, c'est juste ton API qui te permet de passer une valeur arbitraire à ton thread. Généralement, cette valeur arbitraire va être un pointeur vers un contexte que tu auras toi-même mis en place et que tu sauras utiliser dans ton thread.
 
Pour la création des threads instantanés, tu ne peux pas supposer plus que ce que ton API système te propose. Souvent, ton appel système qui demande la création du thread ne va pas être instantané (comprendre : quand tu sors de ton appel système, ton thread n'a pas nécessairement exécuté le moindre bout de code de la fonction que tu lui as passée en argument). Cela dit, selon le nombre de threads que tu crées, tu vas probablement tomber dans le cas où le premier thread a démarré avant que tu n'aies demandé la création du dernier.
 
Bref, ce sont des suppositions que tu ne dois pas faire. Si tu dois faire de la synchro sur le départ des threads, tout système va te proposer une API claire pour te mettre en attente de signaux spécifiques. Selon ton cas, tu pourras donc vouloir que tes threads soient créés dans un état dormant et les réveiller plus tard, ou alors tu pourras vouloir les faire attendre un signal en guise de première instruction (ou, dernier cas, tu les lances et tu t'en fous, ils peuvent tourner et faire le job sans que tu ne te poses de question )