Comment un fil de la fonction accès aux variables de la mère thread
J'ai lu que les threads partagent l'espace d'adressage de mémoire de celle du parent fil.
Si cela est vrai , pourquoi pas une fonction de thread accéder à une variable locale appartenant à celle du parent fil ?
void* PrintVar(void* arg){
printf( "%d\n", a);
}
int main(int argc, char*argv[]) {
int a;
a = 10;
pthread_t thr;
pthread_create( &thr, NULL, PrintVar, NULL );
}
Si le thread des actions de l'espace d'adressage , alors la fonction PrintVar doit avoir été en mesure d'imprimer la valeur de variable a
, droit ?
J'ai lu ce morceau de l'info sur http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
Threads du même processus partagent:
Instructions concernant le processus d'
La plupart des données
ouvrir des fichiers (descripteurs)
les signaux et les gestionnaires de signaux
répertoire de travail courant
L'utilisateur et id de groupe
Si cela est vrai, alors pourquoi ne int a
pas considérée comme une variable partagée ?
J'aimerais voir un exemple de code où les descripteurs de fichiers sont partagés
OriginalL'auteur Sharat Chandra | 2010-10-17
Vous devez vous connecter pour publier un commentaire.
vous ne pouviez pas le faire même si ce n'était pas un thread, parce que l'un est hors de portée.
mettre un dans la portée globale, comme suit:
Ce n'est effectivement pas un problème de threads. considérons le code suivant:
De toute évidence, cela ne fonctionnera pas, parce que le nom de la variable
a
déclaré dansmain
n'est pas visible dansPrintVar
, car c'est dans les locaux de la portée d'un autre bloc. C'est au moment de la compilation problème, le compilateur ne sait tout simplement pas ce que vous entendez para
lorsque vous le mentionner dansPrintVar
.Mais il y a aussi un autre problème thread. lorsque le thread principal d'un processus de sortie, tous les autres threads sont terminées (en particulier, lorsque tout thread appelle
_exit
, puis tous les threads sont terminées, et_start
appels_exit
aprèsmain
retours). mais votre principale renvoie immédiatement après l'invocation de l'autre thread. Pour éviter cela, vous devez appelerpthread_join
qui va attendre un fil à la sortie avant de revenir. qui va ressembler à cecinon, les variables locales sont "partagés", tout autant que rien d'autre. Le problème se pose si vous passer l'adresse d'une variable locale à un autre thread, mais alors la sortie de la fonction (si la variable n'est plus valide), mais l'autre thread ne sait pas qu'il ne peut pas utiliser cette variable.
Non, je veux dire lorsque la fonction dans le parent quitte thread, la variable locale cesse d'exister, donc si vous avez transmis à l'enfant du fil, il est facile pour l'enfant thread (sans le savoir) de continuer à l'utiliser après il n'existe plus.
l'espace d'adressage partagé signifie qu'ils partagent tous le même ensemble d'adresses, une adresse dans un thread est significatif dans l'autre, et se réfère à la même variable. Contrairement à des processus distincts, où une adresse dans un processus ne peut pas dire quoi que ce soit dans un autre, ou peut se référer à quelque chose de complètement différent, de sorte que même si vous essayez de passer d'une adresse à partir d'un processus à un autre, vous n'aurez pas (normalement) être capable de l'utiliser dans les autres processus.
il n'est pas garanti d'être inexistant -- il pourrait se référer à quelque chose dans le processus B, mais en général pas la même chose que dans le processus de A. Le fait qu'il fait référence à quoi que ce soit est surtout une question de limite au nombre d'adresses disponibles, il y a donc au moins un peu de chance il sera valable dans les deux. Dans un système 32 bits, il sera généralement. Dans un système 64 bits (beaucoup plus d'adresses disponibles), il y a beaucoup plus de chance de ne pas être.
OriginalL'auteur SingleNegationElimination
L'enfant thread peut accéder à la variable dans la pile de thread parent, il a juste besoin de savoir la variable de l'adresse. Par exemple, vous pouvez le faire comme ceci:
Noter que ce genre de chose peut être difficile, car vous devez (d'une manière ou d'une autre) garantit que (a) ne sera pas détruit, tandis que l'enfant thread est toujours y accéder. (Dans ce cas, vous auriez probablement souhaitez appeler pthread_join() à la fin de main(), de sorte que le thread principal va bloquer là et pas de retour de main() jusqu'à ce que l'enfant thread a quitté)
Donc, pour résumer ma compréhension : "espace d'adressage partagé" signifie que les variables locales peuvent être partagées par les threads enfants que par explicitement de le transmettre comme un argument à l'enfant thread. - Il Correct ?
"L'espace d'adressage partagé" est en fait réalisé par le "passage" à l'adresse de référence pour le fil , et non pas par d'autres moyens. Droit ?
Les Threads d'un même processus de toujours partager l'ensemble de l'espace d'adressage les uns avec les autres. Mais le simple fait de partager le même espace d'adressage n'est pas suffisant ici -- si vous voulez lire/écrire une variable dans une autre pile du thread (qui, apparemment, ne), vous avez également besoin de connaître l'adresse de cette variable afin de savoir où écrire.
À noter que "l'espace d'adressage partagé" signifie seulement que d'enfiler, une valeur de pointeur de référence le même physique octets de RAM. Voilà qui contraste avec le cas de deux processus différents, où chaque processus peut contenir un pointeur avec la même valeur, mais les deux pointeurs néanmoins le point à deux différents emplacements de mémoire en raison de la mémoire virtuelle de la magie.
OriginalL'auteur Jeremy Friesner