J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait
std::string .
Pourquoi donc?
A part le fait que chaque librairie utilise son propre type CString,
QString ... et que du coup ça fait moche d'utiliser std::string.
Le système d'exploitation Unix est souvent décritr comme multi-tâche. Mais il n'est pas forcément multithread (et pendant longtemps, il ne l'a pas été). Certains spécialistes de système d'exploitation font une différence entre « task » et « thread ».
Différence qui a évoluée à file du temps. Quand j'ai commencé l'informatique, dans les cercles où je me trouvais, il était courant d'utiliser tâche (et l'anglais task) quand les fils différents avait des environements complètement isolés, et processus (anglais process) quand ce n'était pas le cas, par exemple, sur les petits processeurs courants de l'époque, qui ne supportait pas la protection mémoire, etc.
Mais c'était probablement une convention assez localisée, parce que à la même époque, Unix parlait déjà des processus (processes), bien qu'il tournait sur des machines avec protection de la mémoire, comme les PDP-11. (Mais je ne travaillais pas sur Unix à l'époque.)
De toute façon, avec les threads d'aujourd'hui, je rétrouve mes processus de l'époque, à peu près.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
JBB <merci@pasdespam.fr> writes:
| Pourquoi ne pas utiliser multi-tâche.
Le système d'exploitation Unix est souvent décritr comme
multi-tâche. Mais il n'est pas forcément multithread (et
pendant longtemps, il ne l'a pas été). Certains spécialistes
de système d'exploitation font une différence entre « task »
et « thread ».
Différence qui a évoluée à file du temps. Quand j'ai commencé
l'informatique, dans les cercles où je me trouvais, il était
courant d'utiliser tâche (et l'anglais task) quand les fils
différents avait des environements complètement isolés, et
processus (anglais process) quand ce n'était pas le cas, par
exemple, sur les petits processeurs courants de l'époque, qui ne
supportait pas la protection mémoire, etc.
Mais c'était probablement une convention assez localisée, parce
que à la même époque, Unix parlait déjà des processus
(processes), bien qu'il tournait sur des machines avec
protection de la mémoire, comme les PDP-11. (Mais je ne
travaillais pas sur Unix à l'époque.)
De toute façon, avec les threads d'aujourd'hui, je rétrouve mes
processus de l'époque, à peu près.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Le système d'exploitation Unix est souvent décritr comme multi-tâche. Mais il n'est pas forcément multithread (et pendant longtemps, il ne l'a pas été). Certains spécialistes de système d'exploitation font une différence entre « task » et « thread ».
Différence qui a évoluée à file du temps. Quand j'ai commencé l'informatique, dans les cercles où je me trouvais, il était courant d'utiliser tâche (et l'anglais task) quand les fils différents avait des environements complètement isolés, et processus (anglais process) quand ce n'était pas le cas, par exemple, sur les petits processeurs courants de l'époque, qui ne supportait pas la protection mémoire, etc.
Mais c'était probablement une convention assez localisée, parce que à la même époque, Unix parlait déjà des processus (processes), bien qu'il tournait sur des machines avec protection de la mémoire, comme les PDP-11. (Mais je ne travaillais pas sur Unix à l'époque.)
De toute façon, avec les threads d'aujourd'hui, je rétrouve mes processus de l'époque, à peu près.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
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.
-- Gaby
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.
| 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.
-- Gaby
Gabriel Dos Reis
Arnaud Meurgues writes:
| Gabriel Dos Reis wrote: | | > l'a pas été). Certains spécialistes de système d'exploitation font | > une différence entre « task » et « thread ». | | C'est curieux de réserver cette distinction à certains | spécialistes. Il y a des non-spécialistes et d'autres spécialistes qui | ne la font pas ? | | Cela me semble pourtant bien différent.
Oui et je suis d'accord avec toi. Mais regarde un peu le message de James, c'est une petite partie de la petite partie de l'iceberg.
| Gabriel Dos Reis wrote:
|
| > l'a pas été). Certains spécialistes de système d'exploitation font
| > une différence entre « task » et « thread ».
|
| C'est curieux de réserver cette distinction à certains
| spécialistes. Il y a des non-spécialistes et d'autres spécialistes qui
| ne la font pas ?
|
| Cela me semble pourtant bien différent.
Oui et je suis d'accord avec toi. Mais regarde un peu le message de
James, c'est une petite partie de la petite partie de l'iceberg.
| Gabriel Dos Reis wrote: | | > l'a pas été). Certains spécialistes de système d'exploitation font | > une différence entre « task » et « thread ». | | C'est curieux de réserver cette distinction à certains | spécialistes. Il y a des non-spécialistes et d'autres spécialistes qui | ne la font pas ? | | Cela me semble pourtant bien différent.
Oui et je suis d'accord avec toi. Mais regarde un peu le message de James, c'est une petite partie de la petite partie de l'iceberg.
-- Gaby
Laurent Deniau
Benoît Dejean wrote:
Par contre, avec la même sémantique, il faut des opérations particulières au système d'exploitation pour la synchronisation des opérations et je ne sais s'il en existe des versions solides, gratuites et qui fonctionnent sur toutes les plate-formes...
je rêve de chaînes immuables à la Python :/
Et des perfomances a la Pyhton aussi :-?
Benoît Dejean wrote:
Par contre, avec la même sémantique, il faut des opérations
particulières au système d'exploitation pour la synchronisation
des opérations et je ne sais s'il en existe des versions solides,
gratuites et qui fonctionnent sur toutes les plate-formes...
Par contre, avec la même sémantique, il faut des opérations particulières au système d'exploitation pour la synchronisation des opérations et je ne sais s'il en existe des versions solides, gratuites et qui fonctionnent sur toutes les plate-formes...
je rêve de chaînes immuables à la Python :/
Et des perfomances a la Pyhton aussi :-?
kanze
Gabriel Dos Reis wrote:
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.
Soit je me suis mal exprimé, soit tu as mal lu, mais mon point était que sur les processeurs de l'époque, il n'y avait pas de protection mémoire, ni de mapping. L'adresse que tu voyais dans ton programme était l'adresse physique sur la carte mémoire. Et tous les processus avaient accès à toute la mémoire.
À peu près comme un thread dans un processus aujourd'hui.
Quant à fork(), c'est une abhérition de Unix -- la plupart des systèmes sur lesquels j'ai travaillé avaient des mechanismes un peu plus intelligents.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
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.
Soit je me suis mal exprimé, soit tu as mal lu, mais mon point
était que sur les processeurs de l'époque, il n'y avait pas de
protection mémoire, ni de mapping. L'adresse que tu voyais dans
ton programme était l'adresse physique sur la carte mémoire. Et
tous les processus avaient accès à toute la mémoire.
À peu près comme un thread dans un processus aujourd'hui.
Quant à fork(), c'est une abhérition de Unix -- la plupart des
systèmes sur lesquels j'ai travaillé avaient des mechanismes un
peu plus intelligents.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| 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.
Soit je me suis mal exprimé, soit tu as mal lu, mais mon point était que sur les processeurs de l'époque, il n'y avait pas de protection mémoire, ni de mapping. L'adresse que tu voyais dans ton programme était l'adresse physique sur la carte mémoire. Et tous les processus avaient accès à toute la mémoire.
À peu près comme un thread dans un processus aujourd'hui.
Quant à fork(), c'est une abhérition de Unix -- la plupart des systèmes sur lesquels j'ai travaillé avaient des mechanismes un peu plus intelligents.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Michel Michaud wrote:
[...]
Non, ici je dirais multi-processus (ou multi « fiss » si tu veux), mais certainement pas multi « file » comme dans multithread... Et ce n'est pas nécessairement avec fork (qui est très unixien).
la même chose que le multithreading (oops, pardon ;)
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.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Michaud wrote:
[...]
Non, ici je dirais multi-processus (ou multi « fiss » si tu
veux), mais certainement pas multi « file » comme dans
multithread... Et ce n'est pas nécessairement avec fork (qui
est très unixien).
la même chose que le multithreading (oops, pardon ;)
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.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Non, ici je dirais multi-processus (ou multi « fiss » si tu veux), mais certainement pas multi « file » comme dans multithread... Et ce n'est pas nécessairement avec fork (qui est très unixien).
la même chose que le multithreading (oops, pardon ;)
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.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
writes:
| Michel Michaud wrote: | | [...] | > Non, ici je dirais multi-processus (ou multi « fiss » si tu | > veux), mais certainement pas multi « file » comme dans | > multithread... Et ce n'est pas nécessairement avec fork (qui | > est très unixien). | | > > la même chose que le multithreading (oops, pardon ;) | | > 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.
Des experts en la matière sont en profond désaccord avec ton assertion. À moins que ton assertion soit une auto-définition. Dans ce cas, je préfère ne pas utiliser ton package de thread ;-}
-- Gaby
kanze@gabi-soft.fr writes:
| Michel Michaud wrote:
|
| [...]
| > Non, ici je dirais multi-processus (ou multi « fiss » si tu
| > veux), mais certainement pas multi « file » comme dans
| > multithread... Et ce n'est pas nécessairement avec fork (qui
| > est très unixien).
|
| > > la même chose que le multithreading (oops, pardon ;)
|
| > 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.
Des experts en la matière sont en profond désaccord avec ton assertion.
À moins que ton assertion soit une auto-définition. Dans ce cas, je
préfère ne pas utiliser ton package de thread ;-}
| Michel Michaud wrote: | | [...] | > Non, ici je dirais multi-processus (ou multi « fiss » si tu | > veux), mais certainement pas multi « file » comme dans | > multithread... Et ce n'est pas nécessairement avec fork (qui | > est très unixien). | | > > la même chose que le multithreading (oops, pardon ;) | | > 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.
Des experts en la matière sont en profond désaccord avec ton assertion. À moins que ton assertion soit une auto-définition. Dans ce cas, je préfère ne pas utiliser ton package de thread ;-}
-- Gaby
Arnaud Meurgues
wrote:
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.
Je ne sais pas si Solaris est un bon ou un mauvais système d'exploitation. Mais il a même une gestion à deux niveaux des threads.
En fait, au sein d'un process, il y a des « light weight processes » (lwp) qui eux-mêmes peuvent faire tourner plusieurs threads. Je crois que ça leur permet de gérer plus facilement (et plus efficacement ?) l'équilibrage de charge entre plusieurs processeurs.
Arnaud
kanze@gabi-soft.fr wrote:
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.
Je ne sais pas si Solaris est un bon ou un mauvais système
d'exploitation. Mais il a même une gestion à deux niveaux des threads.
En fait, au sein d'un process, il y a des « light weight processes »
(lwp) qui eux-mêmes peuvent faire tourner plusieurs threads. Je crois
que ça leur permet de gérer plus facilement (et plus efficacement ?)
l'équilibrage de charge entre plusieurs processeurs.
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.
Je ne sais pas si Solaris est un bon ou un mauvais système d'exploitation. Mais il a même une gestion à deux niveaux des threads.
En fait, au sein d'un process, il y a des « light weight processes » (lwp) qui eux-mêmes peuvent faire tourner plusieurs threads. Je crois que ça leur permet de gérer plus facilement (et plus efficacement ?) l'équilibrage de charge entre plusieurs processeurs.
Arnaud
kanze
Arnaud Meurgues wrote:
wrote:
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.
Je ne sais pas si Solaris est un bon ou un mauvais système d'exploitation.
Quand il s'agit des threads, il n'est pas très bon.
En général, il y a un problème historique dans la plupart des implémentations d'Unix : les threads sont arrivé plus tard, et on a essayé de les ajouter, d'une façon plus ou moins bricolée.
Mais il a même une gestion à deux niveaux des threads.
Pour des raisons historiques. Mais c'est une politique qu'il abandonne.
En fait, au sein d'un process, il y a des « light weight processes » (lwp) qui eux-mêmes peuvent faire tourner plusieurs threads. Je crois que ça leur permet de gérer plus facilement (et plus efficacement ?) l'équilibrage de charge entre plusieurs processeurs.
Le problème, c'est l'inverse, je crois. Au départ, ils ont implémenté un espèce de pseudo-thread, à l'intérieur de leur processus, et qui ne faisaient pas appel au système. Ce qui ne marche qu'à moitié, et qui effectivement fait que deux threads ne peuvent pas tourner en parallel sur deux processeurs différents. (Mais qui contournait le problème que les appels systèmes coûtent chers chez eux, parce qu'il n'en faisait pas.) Par la suite, ils ont introduit les LWP, c-à-d des threads supportaient par le système, afin de palier ces inconvenients. Et sur les versions les plus récentes, il ne supporte plus que les LWP -- l'ancien bricolage disparaît.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues wrote:
kanze@gabi-soft.fr wrote:
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.
Je ne sais pas si Solaris est un bon ou un mauvais système
d'exploitation.
Quand il s'agit des threads, il n'est pas très bon.
En général, il y a un problème historique dans la plupart des
implémentations d'Unix : les threads sont arrivé plus tard, et
on a essayé de les ajouter, d'une façon plus ou moins bricolée.
Mais il a même une gestion à deux niveaux des threads.
Pour des raisons historiques. Mais c'est une politique qu'il
abandonne.
En fait, au sein d'un process, il y a des « light weight
processes » (lwp) qui eux-mêmes peuvent faire tourner
plusieurs threads. Je crois que ça leur permet de gérer plus
facilement (et plus efficacement ?) l'équilibrage de charge
entre plusieurs processeurs.
Le problème, c'est l'inverse, je crois. Au départ, ils ont
implémenté un espèce de pseudo-thread, à l'intérieur de leur
processus, et qui ne faisaient pas appel au système. Ce qui ne
marche qu'à moitié, et qui effectivement fait que deux threads
ne peuvent pas tourner en parallel sur deux processeurs
différents. (Mais qui contournait le problème que les appels
systèmes coûtent chers chez eux, parce qu'il n'en faisait pas.)
Par la suite, ils ont introduit les LWP, c-à-d des threads
supportaient par le système, afin de palier ces inconvenients.
Et sur les versions les plus récentes, il ne supporte plus que
les LWP -- l'ancien bricolage disparaît.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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.
Je ne sais pas si Solaris est un bon ou un mauvais système d'exploitation.
Quand il s'agit des threads, il n'est pas très bon.
En général, il y a un problème historique dans la plupart des implémentations d'Unix : les threads sont arrivé plus tard, et on a essayé de les ajouter, d'une façon plus ou moins bricolée.
Mais il a même une gestion à deux niveaux des threads.
Pour des raisons historiques. Mais c'est une politique qu'il abandonne.
En fait, au sein d'un process, il y a des « light weight processes » (lwp) qui eux-mêmes peuvent faire tourner plusieurs threads. Je crois que ça leur permet de gérer plus facilement (et plus efficacement ?) l'équilibrage de charge entre plusieurs processeurs.
Le problème, c'est l'inverse, je crois. Au départ, ils ont implémenté un espèce de pseudo-thread, à l'intérieur de leur processus, et qui ne faisaient pas appel au système. Ce qui ne marche qu'à moitié, et qui effectivement fait que deux threads ne peuvent pas tourner en parallel sur deux processeurs différents. (Mais qui contournait le problème que les appels systèmes coûtent chers chez eux, parce qu'il n'en faisait pas.) Par la suite, ils ont introduit les LWP, c-à-d des threads supportaient par le système, afin de palier ces inconvenients. Et sur les versions les plus récentes, il ne supporte plus que les LWP -- l'ancien bricolage disparaît.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Gabriel Dos Reis wrote:
writes:
| Michel Michaud wrote:
| [...] | > Non, ici je dirais multi-processus (ou multi « fiss » si | > tu veux), mais certainement pas multi « file » comme dans | > multithread... Et ce n'est pas nécessairement avec fork | > (qui est très unixien).
| > > la même chose que le multithreading (oops, pardon ;)
| > 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.
Des experts en la matière sont en profond désaccord avec ton assertion.
Quels experts ? Et pour quelles raisons ?
À moins que ton assertion soit une auto-définition. Dans ce cas, je préfère ne pas utiliser ton package de thread ;-}
Je ne suis pas l'auteur, mais Linux utilise exactement les principes que je viens de décrire ; tu préfères ne pas utiliser Linux ? D'après j'ai entendu dire, Windows fait pareil (mais je n'ai pas accès aux sources de Windows pour vérifier). Et évidemment, prèsque tous les systèmes temps-réel, qui en plus donne accès à ces bas niveaux.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
kanze@gabi-soft.fr writes:
| Michel Michaud wrote:
| [...]
| > Non, ici je dirais multi-processus (ou multi « fiss » si
| > tu veux), mais certainement pas multi « file » comme dans
| > multithread... Et ce n'est pas nécessairement avec fork
| > (qui est très unixien).
| > > la même chose que le multithreading (oops, pardon ;)
| > 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.
Des experts en la matière sont en profond désaccord avec ton
assertion.
Quels experts ? Et pour quelles raisons ?
À moins que ton assertion soit une auto-définition. Dans ce
cas, je préfère ne pas utiliser ton package de thread ;-}
Je ne suis pas l'auteur, mais Linux utilise exactement les
principes que je viens de décrire ; tu préfères ne pas utiliser
Linux ? D'après j'ai entendu dire, Windows fait pareil (mais je
n'ai pas accès aux sources de Windows pour vérifier). Et
évidemment, prèsque tous les systèmes temps-réel, qui en plus
donne accès à ces bas niveaux.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| [...] | > Non, ici je dirais multi-processus (ou multi « fiss » si | > tu veux), mais certainement pas multi « file » comme dans | > multithread... Et ce n'est pas nécessairement avec fork | > (qui est très unixien).
| > > la même chose que le multithreading (oops, pardon ;)
| > 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.
Des experts en la matière sont en profond désaccord avec ton assertion.
Quels experts ? Et pour quelles raisons ?
À moins que ton assertion soit une auto-définition. Dans ce cas, je préfère ne pas utiliser ton package de thread ;-}
Je ne suis pas l'auteur, mais Linux utilise exactement les principes que je viens de décrire ; tu préfères ne pas utiliser Linux ? D'après j'ai entendu dire, Windows fait pareil (mais je n'ai pas accès aux sources de Windows pour vérifier). Et évidemment, prèsque tous les systèmes temps-réel, qui en plus donne accès à ces bas niveaux.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
