Sous linux, lorsqu'on créé un de mes programme créé un thread
(pthread_create() ), cela créée un processus. C'est dû à la manière dont le
noyau et l'implémentation des threads POSIX sous linux fonctionnent. OK.
Mes questions sont :
1) comment les différents threads partagent leurs variables globales ?
2) la commutation entre deux threads lancés par un même processus est-elle
plus rapide que la commutation entre deux processus qui n'ont rien à voir ?
Merci...
-----
Charles Bouilllaguet
www.moostik.net (bzz bzz)
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles Magnier
Charles Bouillaguet wrote:
bonjour,
Bonjour,
Sous linux, lorsqu'on créé un de mes programme créé un thread (pthread_create() ), cela créée un processus. C'est dû à la manière dont le
eu non pas des processus à part entière : un thread ou LWP Light weight Process
noyau et l'implémentation des threads POSIX sous linux fonctionnent. OK. Mes questions sont : 1) comment les différents threads partagent leurs variables globales ?
un executable en mémoire est composé de 3 "zones" dans l'espace d'adressage :
les DATA (code + variables globales), le TAS (HEAP) qui est la zone d'allocation dynamique de la mémoire et la PILE (STACK) qui est la zone servant pour les appels de fonctions(en gros).
Deux thread d'un même programme on uniquement des piles distinctes, le reste est partagé.
Par conséquent il est tout a fait possible de passer une adresse d'une variable alloué dynamiquement d'un thread à un autre.
2) la commutation entre deux threads lancés par un même processus est-elle plus rapide que la commutation entre deux processus qui n'ont rien à voir ?
pour etablir une communication entre deux processus il faut passer par les méchanismes d'IPC tels que les pipes, shared memory, semaphore etc.. chaque méthode a ses avantages et ses inconvéniants mais généralement les IPC sont assez lent comparés à la communication entre deux threads (puisque celle ci se fait via le tas)
pour plus de détail je te renvoie vers quelques documents : (note que ce sont des documents non fini particulièrement peuplés de fautes d'orthographe...)
http://www.labo-unix.org/gilles/pthread_beta1.pdf d'autres exemples + doc ipc : http://www.labo-unix.org/gilles/
Cordialement,
Gilles.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Charles Bouillaguet wrote:
bonjour,
Bonjour,
Sous linux, lorsqu'on créé un de mes programme créé un thread
(pthread_create() ), cela créée un processus. C'est dû à la manière dont le
eu non pas des processus à part entière : un thread ou LWP Light weight
Process
noyau et l'implémentation des threads POSIX sous linux fonctionnent. OK.
Mes questions sont :
1) comment les différents threads partagent leurs variables globales ?
un executable en mémoire est composé de 3 "zones" dans l'espace
d'adressage :
les DATA (code + variables globales), le TAS (HEAP) qui est la zone
d'allocation
dynamique de la mémoire et la PILE (STACK) qui est la zone servant pour
les appels
de fonctions(en gros).
Deux thread d'un même programme on uniquement des piles distinctes, le
reste est partagé.
Par conséquent il est tout a fait possible de passer une adresse d'une
variable alloué dynamiquement
d'un thread à un autre.
2) la commutation entre deux threads lancés par un même processus est-elle
plus rapide que la commutation entre deux processus qui n'ont rien à voir ?
pour etablir une communication entre deux processus il faut passer par
les méchanismes
d'IPC tels que les pipes, shared memory, semaphore etc..
chaque méthode a ses avantages et ses inconvéniants mais généralement
les IPC sont assez lent comparés à la communication entre deux threads
(puisque celle ci se fait via le tas)
pour plus de détail je te renvoie vers quelques documents :
(note que ce sont des documents non fini particulièrement peuplés de fautes
d'orthographe...)
http://www.labo-unix.org/gilles/pthread_beta1.pdf
d'autres exemples + doc ipc :
http://www.labo-unix.org/gilles/
Cordialement,
Gilles.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Sous linux, lorsqu'on créé un de mes programme créé un thread (pthread_create() ), cela créée un processus. C'est dû à la manière dont le
eu non pas des processus à part entière : un thread ou LWP Light weight Process
noyau et l'implémentation des threads POSIX sous linux fonctionnent. OK. Mes questions sont : 1) comment les différents threads partagent leurs variables globales ?
un executable en mémoire est composé de 3 "zones" dans l'espace d'adressage :
les DATA (code + variables globales), le TAS (HEAP) qui est la zone d'allocation dynamique de la mémoire et la PILE (STACK) qui est la zone servant pour les appels de fonctions(en gros).
Deux thread d'un même programme on uniquement des piles distinctes, le reste est partagé.
Par conséquent il est tout a fait possible de passer une adresse d'une variable alloué dynamiquement d'un thread à un autre.
2) la commutation entre deux threads lancés par un même processus est-elle plus rapide que la commutation entre deux processus qui n'ont rien à voir ?
pour etablir une communication entre deux processus il faut passer par les méchanismes d'IPC tels que les pipes, shared memory, semaphore etc.. chaque méthode a ses avantages et ses inconvéniants mais généralement les IPC sont assez lent comparés à la communication entre deux threads (puisque celle ci se fait via le tas)
pour plus de détail je te renvoie vers quelques documents : (note que ce sont des documents non fini particulièrement peuplés de fautes d'orthographe...)
http://www.labo-unix.org/gilles/pthread_beta1.pdf d'autres exemples + doc ipc : http://www.labo-unix.org/gilles/
Cordialement,
Gilles.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Pierre Vigneras
>>>>> "Charles" == Charles Bouillaguet writes:
Charles> bonjour, Sous linux, lorsqu'on créé un de mes programme créé un Charles> thread (pthread_create() ), cela créée un processus. C'est dû à la Charles> manière dont le noyau et l'implémentation des threads POSIX sous Charles> linux fonctionnent. OK. Mes questions sont : 1) comment les Charles> différents threads partagent leurs variables globales ? 2) la Charles> commutation entre deux threads lancés par un même processus Charles> est-elle plus rapide que la commutation entre deux processus qui Charles> n'ont rien à voir ?
Si je dis des conneries, n'hesitez pas à me corriger !
Non, sous linux, le scheduler ordonnance des tâches, pas des processus (c'est une légende urbaine : les threads linux, c'est de la daube !).
Lorque la tâche ne partage rien avec d'autre tâches (défaut pour fork()), c'est un processus au sens UNIX du terme. Lorsqu'une tâche partage un certain nombre de données -- signaux, mémoire, descripteur de fichier (c'est paramétrable dans l'appel système clone()), c'est une thread NOYAUX au sens LINUX du terme.
Enfin, l'implémentation POSIX des threads sous linux utilise les threads noyaux linux (mapping 1:1), mais il est tout à fait possible d'implémenter une librairie de threads non POSIX au dessus de l'appel système clone(). Ce serait même probablement mieux. L'API threads POSIX est vraiment difficile à implémenter complètement (gestion des signaux notamment). Mais, c'est la vie...
Au final, on croit voir des processus alors que ce sont des threads, parce que les tâches linux ont un PID (comme les processus UNIX). Je crois que la nouvelle architecture de threads (NPTL il me semble) et la glibc qui la contient résoud ce problème : on ne voit plus qu'un seul processus qui contient des threads.
Donc, l'ordonnancement de tâches est très rapide sous linux (il n'y a pas deux ordonnanceurs, il n'y a que des tâches à ordonnancer), je pense que cela doit être aussi efficace sous linux d'ordonnancer des threads que des processus (modulo le fait que matèrielement, lorsqu'il y a changement de contexte entre deux processus, il y a vidage du cache processeur, tandis que dans le cas des threads, ce n'est pas nécessaire).
Voilà. -- No one equals eipi : -1 = e^(i.Pi)
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
>>>>> "Charles" == Charles Bouillaguet <charles@moostik.net> writes:
Charles> bonjour, Sous linux, lorsqu'on créé un de mes programme créé un
Charles> thread (pthread_create() ), cela créée un processus. C'est dû à la
Charles> manière dont le noyau et l'implémentation des threads POSIX sous
Charles> linux fonctionnent. OK. Mes questions sont : 1) comment les
Charles> différents threads partagent leurs variables globales ? 2) la
Charles> commutation entre deux threads lancés par un même processus
Charles> est-elle plus rapide que la commutation entre deux processus qui
Charles> n'ont rien à voir ?
Si je dis des conneries, n'hesitez pas à me corriger !
Non, sous linux, le scheduler ordonnance des tâches, pas des processus (c'est
une légende urbaine : les threads linux, c'est de la daube !).
Lorque la tâche ne partage rien avec d'autre tâches (défaut pour fork()), c'est
un processus au sens UNIX du terme. Lorsqu'une tâche partage un certain nombre
de données -- signaux, mémoire, descripteur de fichier (c'est paramétrable dans
l'appel système clone()), c'est une thread NOYAUX au sens LINUX du terme.
Enfin, l'implémentation POSIX des threads sous linux utilise les threads noyaux
linux (mapping 1:1), mais il est tout à fait possible d'implémenter une
librairie de threads non POSIX au dessus de l'appel système clone(). Ce serait
même probablement mieux. L'API threads POSIX est vraiment difficile à
implémenter complètement (gestion des signaux notamment). Mais, c'est la vie...
Au final, on croit voir des processus alors que ce sont des threads, parce que
les tâches linux ont un PID (comme les processus UNIX). Je crois que la
nouvelle architecture de threads (NPTL il me semble) et la glibc qui la
contient résoud ce problème : on ne voit plus qu'un seul processus qui contient
des threads.
Donc, l'ordonnancement de tâches est très rapide sous linux (il n'y a pas deux
ordonnanceurs, il n'y a que des tâches à ordonnancer), je pense que cela doit
être aussi efficace sous linux d'ordonnancer des threads que des processus
(modulo le fait que matèrielement, lorsqu'il y a changement de contexte entre
deux processus, il y a vidage du cache processeur, tandis que dans le cas des
threads, ce n'est pas nécessaire).
Voilà.
--
No one equals eipi : -1 = e^(i.Pi)
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Charles> bonjour, Sous linux, lorsqu'on créé un de mes programme créé un Charles> thread (pthread_create() ), cela créée un processus. C'est dû à la Charles> manière dont le noyau et l'implémentation des threads POSIX sous Charles> linux fonctionnent. OK. Mes questions sont : 1) comment les Charles> différents threads partagent leurs variables globales ? 2) la Charles> commutation entre deux threads lancés par un même processus Charles> est-elle plus rapide que la commutation entre deux processus qui Charles> n'ont rien à voir ?
Si je dis des conneries, n'hesitez pas à me corriger !
Non, sous linux, le scheduler ordonnance des tâches, pas des processus (c'est une légende urbaine : les threads linux, c'est de la daube !).
Lorque la tâche ne partage rien avec d'autre tâches (défaut pour fork()), c'est un processus au sens UNIX du terme. Lorsqu'une tâche partage un certain nombre de données -- signaux, mémoire, descripteur de fichier (c'est paramétrable dans l'appel système clone()), c'est une thread NOYAUX au sens LINUX du terme.
Enfin, l'implémentation POSIX des threads sous linux utilise les threads noyaux linux (mapping 1:1), mais il est tout à fait possible d'implémenter une librairie de threads non POSIX au dessus de l'appel système clone(). Ce serait même probablement mieux. L'API threads POSIX est vraiment difficile à implémenter complètement (gestion des signaux notamment). Mais, c'est la vie...
Au final, on croit voir des processus alors que ce sont des threads, parce que les tâches linux ont un PID (comme les processus UNIX). Je crois que la nouvelle architecture de threads (NPTL il me semble) et la glibc qui la contient résoud ce problème : on ne voit plus qu'un seul processus qui contient des threads.
Donc, l'ordonnancement de tâches est très rapide sous linux (il n'y a pas deux ordonnanceurs, il n'y a que des tâches à ordonnancer), je pense que cela doit être aussi efficace sous linux d'ordonnancer des threads que des processus (modulo le fait que matèrielement, lorsqu'il y a changement de contexte entre deux processus, il y a vidage du cache processeur, tandis que dans le cas des threads, ce n'est pas nécessaire).
Voilà. -- No one equals eipi : -1 = e^(i.Pi)
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
David MENTRE
Bonjour,
Pierre Vigneras writes:
Donc, l'ordonnancement de tâches est très rapide sous linux (il n'y a pas deux ordonnanceurs, il n'y a que des tâches à ordonnancer), je pense que cela doit être aussi efficace sous linux d'ordonnancer des threads que des processus
J'aurais tendance à dire que le surcoût du changement de processus est lié :
1. à l'algo de sélection du nouveau processus et aux structures de données associées (cf. les efforts récurents sur des SMP pour éviter le partage des structures de données) ;
2. au changement du contexte d'exécution (registres du processeur) ;
3. au changement du contexte mémoire (table des pages).
Dans le cas de Linux, on ne gagne avec des threads que sur le point 3.
(modulo le fait que matèrielement, lorsqu'il y a changement de contexte entre deux processus, il y a vidage du cache processeur,
Non. Vider le cache dépend de l'architecture.
Sur x86, les caches sont indexés par adresse physique et il n'y a donc pas besoin de les vider. Sur MIPS, sauf erreur de ma part, un /tag/ identifie le processus (càd dire un nombre de taille limité, je dirais entre 0 et 127 ou 255). En cas de conflit de tag, il faut vider le cache mais ce n'est pas systématique si le tag est bien choisit.
Amicalement, d. -- David Mentré
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Bonjour,
Pierre Vigneras <eipi@nerim.net> writes:
Donc, l'ordonnancement de tâches est très rapide sous linux (il n'y a pas deux
ordonnanceurs, il n'y a que des tâches à ordonnancer), je pense que cela doit
être aussi efficace sous linux d'ordonnancer des threads que des processus
J'aurais tendance à dire que le surcoût du changement de processus est
lié :
1. à l'algo de sélection du nouveau processus et aux structures de
données associées (cf. les efforts récurents sur des SMP pour éviter
le partage des structures de données) ;
2. au changement du contexte d'exécution (registres du processeur) ;
3. au changement du contexte mémoire (table des pages).
Dans le cas de Linux, on ne gagne avec des threads que sur le point 3.
(modulo le fait que matèrielement, lorsqu'il y a changement de contexte entre
deux processus, il y a vidage du cache processeur,
Non. Vider le cache dépend de l'architecture.
Sur x86, les caches sont indexés par adresse physique et il n'y a donc
pas besoin de les vider. Sur MIPS, sauf erreur de ma part, un /tag/
identifie le processus (càd dire un nombre de taille limité, je dirais
entre 0 et 127 ou 255). En cas de conflit de tag, il faut vider le cache
mais ce n'est pas systématique si le tag est bien choisit.
Amicalement,
d.
--
David Mentré
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Donc, l'ordonnancement de tâches est très rapide sous linux (il n'y a pas deux ordonnanceurs, il n'y a que des tâches à ordonnancer), je pense que cela doit être aussi efficace sous linux d'ordonnancer des threads que des processus
J'aurais tendance à dire que le surcoût du changement de processus est lié :
1. à l'algo de sélection du nouveau processus et aux structures de données associées (cf. les efforts récurents sur des SMP pour éviter le partage des structures de données) ;
2. au changement du contexte d'exécution (registres du processeur) ;
3. au changement du contexte mémoire (table des pages).
Dans le cas de Linux, on ne gagne avec des threads que sur le point 3.
(modulo le fait que matèrielement, lorsqu'il y a changement de contexte entre deux processus, il y a vidage du cache processeur,
Non. Vider le cache dépend de l'architecture.
Sur x86, les caches sont indexés par adresse physique et il n'y a donc pas besoin de les vider. Sur MIPS, sauf erreur de ma part, un /tag/ identifie le processus (càd dire un nombre de taille limité, je dirais entre 0 et 127 ou 255). En cas de conflit de tag, il faut vider le cache mais ce n'est pas systématique si le tag est bien choisit.
Amicalement, d. -- David Mentré
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
