Michel Michaud wrote:Effectivement c'est loin d'être la même chose que le
multithread et je suis heureux que ce soit plus simple, car
c'est ce que j'ai à enseigner :-) (ce n'est pas moi qui
enseigne vraiment la programmation multithread).
Attention. Si les utilisatoins naïves des threads et des
processus sont différentes, dans un bon système d'exploitation
(et je crois qu'à cet égard, les Windows modernes sont de bons
systèmes d'exploitation), il n'y a pas vraiment de différence.
Le système connaît en premier lieu des threads (dans la
terminologie moderne). À chaque thread est associé un certain
nombre de ressources, qui peuvent être partagé ou non. Et en fin
de compte, même pour l'utilisateur, où est la différence entre
un processus multithread avec de la mémoire spécifique à chaque
thread, et des processus avec de la mémoire partagée.
En fait, quand on me dit « multithread », je m'attends à ce que
la mémoire où se trouve les piles fassent partie des ressources
partagée, et quand on parle de plusieurs processus, qu'elle n'en
fasse pas partie.
Mais même là -- au moins sous Posix (et ça
m'étonnera que ce ne soit pas le cas sous Windows aussi), je
peux créer des threads avec des piles dans de la mémoire
partagée, accessibles depuis d'autres processus.
Note bien aussi
que sous Posix (et probablement sous Windows aussi), si un
mutex, un rwlock, une condition variable ou un semaphore se
trouve dans la mémoire partagée, il peut synchroniser des
threads dans des processus différents.
Michel Michaud wrote:
Effectivement c'est loin d'être la même chose que le
multithread et je suis heureux que ce soit plus simple, car
c'est ce que j'ai à enseigner :-) (ce n'est pas moi qui
enseigne vraiment la programmation multithread).
Attention. Si les utilisatoins naïves des threads et des
processus sont différentes, dans un bon système d'exploitation
(et je crois qu'à cet égard, les Windows modernes sont de bons
systèmes d'exploitation), il n'y a pas vraiment de différence.
Le système connaît en premier lieu des threads (dans la
terminologie moderne). À chaque thread est associé un certain
nombre de ressources, qui peuvent être partagé ou non. Et en fin
de compte, même pour l'utilisateur, où est la différence entre
un processus multithread avec de la mémoire spécifique à chaque
thread, et des processus avec de la mémoire partagée.
En fait, quand on me dit « multithread », je m'attends à ce que
la mémoire où se trouve les piles fassent partie des ressources
partagée, et quand on parle de plusieurs processus, qu'elle n'en
fasse pas partie.
Mais même là -- au moins sous Posix (et ça
m'étonnera que ce ne soit pas le cas sous Windows aussi), je
peux créer des threads avec des piles dans de la mémoire
partagée, accessibles depuis d'autres processus.
Note bien aussi
que sous Posix (et probablement sous Windows aussi), si un
mutex, un rwlock, une condition variable ou un semaphore se
trouve dans la mémoire partagée, il peut synchroniser des
threads dans des processus différents.
Michel Michaud wrote:Effectivement c'est loin d'être la même chose que le
multithread et je suis heureux que ce soit plus simple, car
c'est ce que j'ai à enseigner :-) (ce n'est pas moi qui
enseigne vraiment la programmation multithread).
Attention. Si les utilisatoins naïves des threads et des
processus sont différentes, dans un bon système d'exploitation
(et je crois qu'à cet égard, les Windows modernes sont de bons
systèmes d'exploitation), il n'y a pas vraiment de différence.
Le système connaît en premier lieu des threads (dans la
terminologie moderne). À chaque thread est associé un certain
nombre de ressources, qui peuvent être partagé ou non. Et en fin
de compte, même pour l'utilisateur, où est la différence entre
un processus multithread avec de la mémoire spécifique à chaque
thread, et des processus avec de la mémoire partagée.
En fait, quand on me dit « multithread », je m'attends à ce que
la mémoire où se trouve les piles fassent partie des ressources
partagée, et quand on parle de plusieurs processus, qu'elle n'en
fasse pas partie.
Mais même là -- au moins sous Posix (et ça
m'étonnera que ce ne soit pas le cas sous Windows aussi), je
peux créer des threads avec des piles dans de la mémoire
partagée, accessibles depuis d'autres processus.
Note bien aussi
que sous Posix (et probablement sous Windows aussi), si un
mutex, un rwlock, une condition variable ou un semaphore se
trouve dans la mémoire partagée, il peut synchroniser des
threads dans des processus différents.
On Tue, 12 Jul 2005 12:41:34 -0400, "Michel Michaud" :Je ne crois pas que nous sommes personnellement plus
hostile que vous, et nos autorités linguistiques non plus...
Disons que c'est la réputation que vous avez de ce côté-ci de
l'Atlantique.
Euh, l'évolution d'une langue n'est-elle pas justement l'ajout de
nouveaux mots ?
Oui, mais par les voies naturelles de l'évolution de la langue, pas
par l'autorité de quarante guignols verdâtres en épée.
On Tue, 12 Jul 2005 12:41:34 -0400, "Michel Michaud" <mm@gdzid.com>:
Je ne crois pas que nous sommes personnellement plus
hostile que vous, et nos autorités linguistiques non plus...
Disons que c'est la réputation que vous avez de ce côté-ci de
l'Atlantique.
Euh, l'évolution d'une langue n'est-elle pas justement l'ajout de
nouveaux mots ?
Oui, mais par les voies naturelles de l'évolution de la langue, pas
par l'autorité de quarante guignols verdâtres en épée.
On Tue, 12 Jul 2005 12:41:34 -0400, "Michel Michaud" :Je ne crois pas que nous sommes personnellement plus
hostile que vous, et nos autorités linguistiques non plus...
Disons que c'est la réputation que vous avez de ce côté-ci de
l'Atlantique.
Euh, l'évolution d'une langue n'est-elle pas justement l'ajout de
nouveaux mots ?
Oui, mais par les voies naturelles de l'évolution de la langue, pas
par l'autorité de quarante guignols verdâtres en épée.
"Michel Michaud" writes:Dans le message ,Merci, je ne confonds rien :-)
Il faudrait alors que tu m'expliques pourquoi tu penses que nous
sommes pire...
J'ai dit que vous étiez pires ? Tu m'apprends quelque chose.
"Michel Michaud" <mm@gdzid.com> writes:
Dans le message m364vh4ibn.fsf@uniton.integrable-solutions.net,
Merci, je ne confonds rien :-)
Il faudrait alors que tu m'expliques pourquoi tu penses que nous
sommes pire...
J'ai dit que vous étiez pires ? Tu m'apprends quelque chose.
"Michel Michaud" writes:Dans le message ,Merci, je ne confonds rien :-)
Il faudrait alors que tu m'expliques pourquoi tu penses que nous
sommes pire...
J'ai dit que vous étiez pires ? Tu m'apprends quelque chose.
La récente édition de « Advanced Unix Programming » contient pas mal
de discussion sur les diverses POSIX et variations dans les
systèmes.
La récente édition de « Advanced Unix Programming » contient pas mal
de discussion sur les diverses POSIX et variations dans les
systèmes.
La récente édition de « Advanced Unix Programming » contient pas mal
de discussion sur les diverses POSIX et variations dans les
systèmes.
La récente édition de « Advanced Unix Programming » contient pas mal
de discussion sur les diverses POSIX et variations dans les
systèmes.
La récente édition de « Advanced Unix Programming » contient pas mal
de discussion sur les diverses POSIX et variations dans les
systèmes.
La récente édition de « Advanced Unix Programming » contient pas mal
de discussion sur les diverses POSIX et variations dans les
systèmes.
Dans le message ,writes:De toute façon, avec les threads d'aujourd'hui, je rétrouve
mes processus de l'époque, à peu près.
Et la différence est dans le « à peu près » ; et en fait
c'est une grande différence ! Un thread s'éxecute dans le
même espace d'adressage que le processus « maître », alors
qu'avec la programmation multi-tâche avevc fork(), on se
retrouve avec duplication d'instance du programmes.
Et en pratique, c'est bien rare qu'on en reste là. C'est ce
que force la création de processus sous Unix, mais pas
ailleurs. Après le fork sous Unix, on remplace le plus souvent
le programme qui s'exécute par un autre. Sous d'autres SE, on
crée directement l'autre processus avec le bon programme.
Pour moi, il y a aussi d'autres différences majeures entre le
multi-processus et le multi-thread, la principale étant que
les primitives de communications inter-processus sont
habituellement plus sûres et plus simples à utiliser que ce
qu'on fait avec le multi-thread (on pourrait les utiliser là
aussi, mais on ne veut généralement pas, pour des raisons
d'efficacité).
Dans le message m3k6jxe1ct.fsf@uniton.integrable-solutions.net,
kanze@gabi-soft.fr writes:
De toute façon, avec les threads d'aujourd'hui, je rétrouve
mes processus de l'époque, à peu près.
Et la différence est dans le « à peu près » ; et en fait
c'est une grande différence ! Un thread s'éxecute dans le
même espace d'adressage que le processus « maître », alors
qu'avec la programmation multi-tâche avevc fork(), on se
retrouve avec duplication d'instance du programmes.
Et en pratique, c'est bien rare qu'on en reste là. C'est ce
que force la création de processus sous Unix, mais pas
ailleurs. Après le fork sous Unix, on remplace le plus souvent
le programme qui s'exécute par un autre. Sous d'autres SE, on
crée directement l'autre processus avec le bon programme.
Pour moi, il y a aussi d'autres différences majeures entre le
multi-processus et le multi-thread, la principale étant que
les primitives de communications inter-processus sont
habituellement plus sûres et plus simples à utiliser que ce
qu'on fait avec le multi-thread (on pourrait les utiliser là
aussi, mais on ne veut généralement pas, pour des raisons
d'efficacité).
Dans le message ,writes:De toute façon, avec les threads d'aujourd'hui, je rétrouve
mes processus de l'époque, à peu près.
Et la différence est dans le « à peu près » ; et en fait
c'est une grande différence ! Un thread s'éxecute dans le
même espace d'adressage que le processus « maître », alors
qu'avec la programmation multi-tâche avevc fork(), on se
retrouve avec duplication d'instance du programmes.
Et en pratique, c'est bien rare qu'on en reste là. C'est ce
que force la création de processus sous Unix, mais pas
ailleurs. Après le fork sous Unix, on remplace le plus souvent
le programme qui s'exécute par un autre. Sous d'autres SE, on
crée directement l'autre processus avec le bon programme.
Pour moi, il y a aussi d'autres différences majeures entre le
multi-processus et le multi-thread, la principale étant que
les primitives de communications inter-processus sont
habituellement plus sûres et plus simples à utiliser que ce
qu'on fait avec le multi-thread (on pourrait les utiliser là
aussi, mais on ne veut généralement pas, pour des raisons
d'efficacité).
