fonction fork() sous windows...

adebaene

08/10/2004 à 11:43

Cyrille Szymanski wrote in message news:...

Le 07-10-2004, Dominique Vaufreydaz
a écrit :
> Qu'entends-tu par legerete des processus ???

Tel que je vois la chose, les threads n'existant pas sous unix et ses
variantes (jusqu'à l'apparition récente des pthreads) et fork() étant
*la* méthode pour créer des serveurs, cette technique a été très vite
optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une
part la création de forks() est rapide et dans le sens où
l'ordonnanceur est efficace car optimisé dès le début pour un grand
nombre de processus.

Tu parles d'optimisation et d'efficacité, autant d'éléments qui sont
spécifiques à chaque implémentation d'Unix, donc il est difficile de
parler "dans l'absolu".

Ensuite, sans même parler des magouilles d'optimisation,
l'ordonnanceur a plus de boulot à faire pour passer d'un thread à un
autre thread du même processus que d'un processus à l'autre:

- Dans le 1er cas, il "suffit" de mettre à jour l'ensemble des
registres de travail du processeur et le pointeur d'instructions (EIP
sur un x86).

- Dans le 2ème cas, il faut en plus remettre à jour toutes les tables
de mapping entre addresses logiques et addresses physiques (le
registre CR3 sur les X86), mais surtout, comme on change d'espace
d'adressage virtuel, il y a beaucoup plus de chances d'avoir un grand
nombre de fautes de pages par la suite, avec nécessité de swapper de
la mémoire sur disque.

Sous Windows au contraire l'existence des threads a probablement fait
que c'est cette méthode qui a été privilégiée (peut-être au détriment
des processus). La création de processus est plus lente et c'est pour
cela qu'utiliser des threads est *la* méthode de choix pour effectuer
des traitements en parallèle sous Windows. Et l'ordonnanceur est
efficace car optimisé dès le début pour un grand nombre de threads.

C'est surtout que l'ordonnanceur ne *connait pas* la notion de
processus. L'ordonnanceur est une des fonctionnalités du noyau
(kernel), alors que la notion d'espace d'adressage virtuel, de
protection mémoire et de processus est implémentée dans l'executive,
au dessus du kernel.

La preuve : La X-Box fonctionne sur un noyau Windows 2000 où il n'y a
que le kernel : sur ce système, on a donc des threads mais pas de
processus (pas de notion d'espace d'adressage séparé).

Pour faire des essais il n'y a qu'à écrire un serveur basique, 1
fork() par connexion sous unix et 1 *processus* par connexion sous
windows, et regarder le résultat.

Regarder quel résultat? Mesurer les temps d'execution? Il y a
tellement d'autres paramètres qui rendent en compte que ca ne veut pas
dire grand chose comme comparaison (à part que telle solution est plus
efficace au global que telle autre dans telles conditions).

Arnaud

Cyrille Szymanski <cns2@cns.invalid> wrote in message news:<slrncmaoid.ei.cns2@szymanski4.rez-gif.supelec.fr>...

Le 07-10-2004, Dominique Vaufreydaz
<Dominique-Doms.Vaufreydaz@imag.fr> a écrit :
> Qu'entends-tu par legerete des processus ???

Tel que je vois la chose, les threads n'existant pas sous unix et ses
variantes (jusqu'à l'apparition récente des pthreads) et fork() étant
*la* méthode pour créer des serveurs, cette technique a été très vite
optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une
part la création de forks() est rapide et dans le sens où
l'ordonnanceur est efficace car optimisé dès le début pour un grand
nombre de processus.

Tu parles d'optimisation et d'efficacité, autant d'éléments qui sont
spécifiques à chaque implémentation d'Unix, donc il est difficile de
parler "dans l'absolu".

Ensuite, sans même parler des magouilles d'optimisation,
l'ordonnanceur a plus de boulot à faire pour passer d'un thread à un
autre thread du même processus que d'un processus à l'autre:

- Dans le 1er cas, il "suffit" de mettre à jour l'ensemble des
registres de travail du processeur et le pointeur d'instructions (EIP
sur un x86).

- Dans le 2ème cas, il faut en plus remettre à jour toutes les tables
de mapping entre addresses logiques et addresses physiques (le
registre CR3 sur les X86), mais surtout, comme on change d'espace
d'adressage virtuel, il y a beaucoup plus de chances d'avoir un grand
nombre de fautes de pages par la suite, avec nécessité de swapper de
la mémoire sur disque.

Sous Windows au contraire l'existence des threads a probablement fait
que c'est cette méthode qui a été privilégiée (peut-être au détriment
des processus). La création de processus est plus lente et c'est pour
cela qu'utiliser des threads est *la* méthode de choix pour effectuer
des traitements en parallèle sous Windows. Et l'ordonnanceur est
efficace car optimisé dès le début pour un grand nombre de threads.

C'est surtout que l'ordonnanceur ne *connait pas* la notion de
processus. L'ordonnanceur est une des fonctionnalités du noyau
(kernel), alors que la notion d'espace d'adressage virtuel, de
protection mémoire et de processus est implémentée dans l'executive,
au dessus du kernel.

La preuve : La X-Box fonctionne sur un noyau Windows 2000 où il n'y a
que le kernel : sur ce système, on a donc des threads mais pas de
processus (pas de notion d'espace d'adressage séparé).

Pour faire des essais il n'y a qu'à écrire un serveur basique, 1
fork() par connexion sous unix et 1 *processus* par connexion sous
windows, et regarder le résultat.

Regarder quel résultat? Mesurer les temps d'execution? Il y a
tellement d'autres paramètres qui rendent en compte que ca ne veut pas
dire grand chose comme comparaison (à part que telle solution est plus
efficace au global que telle autre dans telles conditions).

Arnaud

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Szymanski wrote in message news:...

Le 07-10-2004, Dominique Vaufreydaz
a écrit :
> Qu'entends-tu par legerete des processus ???

Tel que je vois la chose, les threads n'existant pas sous unix et ses
variantes (jusqu'à l'apparition récente des pthreads) et fork() étant
*la* méthode pour créer des serveurs, cette technique a été très vite
optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une
part la création de forks() est rapide et dans le sens où
l'ordonnanceur est efficace car optimisé dès le début pour un grand
nombre de processus.

Tu parles d'optimisation et d'efficacité, autant d'éléments qui sont
spécifiques à chaque implémentation d'Unix, donc il est difficile de
parler "dans l'absolu".

Ensuite, sans même parler des magouilles d'optimisation,
l'ordonnanceur a plus de boulot à faire pour passer d'un thread à un
autre thread du même processus que d'un processus à l'autre:

- Dans le 1er cas, il "suffit" de mettre à jour l'ensemble des
registres de travail du processeur et le pointeur d'instructions (EIP
sur un x86).

- Dans le 2ème cas, il faut en plus remettre à jour toutes les tables
de mapping entre addresses logiques et addresses physiques (le
registre CR3 sur les X86), mais surtout, comme on change d'espace
d'adressage virtuel, il y a beaucoup plus de chances d'avoir un grand
nombre de fautes de pages par la suite, avec nécessité de swapper de
la mémoire sur disque.

Sous Windows au contraire l'existence des threads a probablement fait
que c'est cette méthode qui a été privilégiée (peut-être au détriment
des processus). La création de processus est plus lente et c'est pour
cela qu'utiliser des threads est *la* méthode de choix pour effectuer
des traitements en parallèle sous Windows. Et l'ordonnanceur est
efficace car optimisé dès le début pour un grand nombre de threads.

C'est surtout que l'ordonnanceur ne *connait pas* la notion de
processus. L'ordonnanceur est une des fonctionnalités du noyau
(kernel), alors que la notion d'espace d'adressage virtuel, de
protection mémoire et de processus est implémentée dans l'executive,
au dessus du kernel.

La preuve : La X-Box fonctionne sur un noyau Windows 2000 où il n'y a
que le kernel : sur ce système, on a donc des threads mais pas de
processus (pas de notion d'espace d'adressage séparé).

Pour faire des essais il n'y a qu'à écrire un serveur basique, 1
fork() par connexion sous unix et 1 *processus* par connexion sous
windows, et regarder le résultat.

Regarder quel résultat? Mesurer les temps d'execution? Il y a
tellement d'autres paramètres qui rendent en compte que ca ne veut pas
dire grand chose comme comparaison (à part que telle solution est plus
efficace au global que telle autre dans telles conditions).

Arnaud

Patrick Philippot

08/10/2004 à 12:39

Arnaud Debaene wrote:

Cyrille Szymanski wrote in message
Ensuite, sans même parler des magouilles d'optimisation,
l'ordonnanceur a plus de boulot à faire pour passer d'un thread à un
autre thread du même processus que d'un processus à l'autre:

- Dans le 1er cas, il "suffit" de mettre à jour l'ensemble des
registres de travail du processeur et le pointeur d'instructions (EIP
sur un x86).

- Dans le 2ème cas, il faut en plus remettre à jour toutes les tables
de mapping entre addresses logiques et addresses physiques (le
registre CR3 sur les X86), mais surtout, comme on change d'espace
d'adressage virtuel, il y a beaucoup plus de chances d'avoir un grand
nombre de fautes de pages par la suite, avec nécessité de swapper de
la mémoire sur disque.

Bonjour Arnaud,

a plus de boulot ==> a moins de boulot (d'après ta démonstration).

Dans les deux cas cependant, il faut aussi mettre à jour la pile du
thread et traiter éventuellement les TLS (quoique ça ne doit pas coûter
très cher, ça).

C'est surtout que l'ordonnanceur ne *connait pas* la notion de
processus. L'ordonnanceur est une des fonctionnalités du noyau
(kernel), alors que la notion d'espace d'adressage virtuel, de
protection mémoire et de processus est implémentée dans l'executive,
au dessus du kernel.

Oui, chaque sous-système (Win32, Posix,...) a sa propre vision de ce
qu'est un processus mais basée sur un objet process unique. C'est ça que
j'aime bien dans cette architecture, cette possibilité d'aouter (ou de
retirer) des sous-systèmes sans toucher au kernel.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Cyrille Szymanski

08/10/2004 à 15:00

Le 08-10-2004, Arnaud Debaene a écrit :

Tu parles d'optimisation et d'efficacité, autant d'éléments qui sont
spécifiques à chaque implémentation d'Unix, donc il est difficile de
parler "dans l'absolu".

Oui et c'est pour cette raison que j'ai pris la peine de préciser :

Et d'autre part il y a une quantité d'unix différents et ce qui est
vrai pour l'un ne l'est pas forcément pour un autre - pour ne citer
qu'un exemple, les ordonnanceurs n'ont rien à voir entre eux,

Ensuite, sans même parler des magouilles d'optimisation,
l'ordonnanceur a plus de boulot à faire pour passer d'un thread à un
autre thread du même processus que d'un processus à l'autre:

C'est plutôt l'inverse, non ?

De toute façon, le sujet n'est pas "pour ou contre fork()" - je vote
contre - mais "CreateProcess() est-il une alternative à fork()" ? En
fait ce n'est même plus un sujet de discussion vu que la réponse a
déjà été donnée, entres autres par Patrick Philippot.

Pour faire des essais il n'y a qu'à écrire un serveur basique, 1
fork() par connexion sous unix et 1 *processus* par connexion sous
windows, et regarder le résultat.

Regarder quel résultat? Mesurer les temps d'execution? Il y a
tellement d'autres paramètres qui rendent en compte que ca ne veut
pas dire grand chose comme comparaison (à part que telle solution
est plus efficace au global que telle autre dans telles conditions).

L'idée de base c'était tout simplement de dire qu'utiliser
CreateProcess() pour reproduire le comportement de fork() n'est pas
une bonne idée. Et que si avoir beaucoup de processus fonctionne
généralement bien sous unix, ce n'est pas le cas sous windows, très
probablement pour des raisons historiques.

--
cns

Yalbrieux

10/10/2004 à 16:18

Bonjour,

"AMcD®" a écrit

Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à manipuler le
MMU et la mémoire protégée. Unix a été écrit par de pauvres gens qui
n'avaient pas les moyens d'acheter un dispendieux Multics. Je crois que vous
seriez plus à même que moi d'en raconter l'histoire.
Ce que je voulais dire c'est que Windows doit rester le plus compatible
possible dans ses diverses versions et traîne quelques boulets. Ce n'est pas
une critique du tout.

Tiens donc ! Que je sache, je peux utiliser plusieurs applications en même
temps, c'est donc bien multi-tâches. Et puis, tant que tu n'as qu'un
processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.
Ce que j'appelle multi-tâche s'applique à un OS qui sait changer de contexte
sur interruption (vieille invention de Xerox je crois) alors que W1, 2 et 3
traitaient les tâches commes des routines. Depuis W9x a su faire ainsi que
NT (qui a hérité du savoir faire d'équipes provenant de l'excellent VMS si
j'ai bonne mémoire ?). Je vous laisse la parole pour expliquer clairement
(je flatte, je flatte ...) qu'une tâche n'est pas un problème de
multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul utilisateur
donc.
Un OS comme UNIX se doit de permettre à plusieurs utilisateurs simultanés de
lancer des programmes qui peuvent eux-mêmes se dérouler en plusieurs tâches.
Je pourrais même ajouter au dessus de tout ça le multi-traitement, c'est à
dire le batch et le temps réel simultanés, le tout en multi-utilisateurs
faisant eux-même du multi-tâches.
Ca vous rappelle des souvenirs ?

En ce qui concerne donc les threads, je pense qu'il n'y a pas matière à
comparaison et que Linux comme Windows sont adapté à une informatique sur un
matériel que l'on ne pouvait pas imaginer à
l'époque de UNIX.

Sauf intérêt spécial je ne prolongerai pas ce fil.
Pardon d'avoir été un peu long et bonne fin de w.e.
Yves

Bonjour,

"AMcD®" <arnold.mcdonald@free.fr> a écrit

Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à manipuler le
MMU et la mémoire protégée. Unix a été écrit par de pauvres gens qui
n'avaient pas les moyens d'acheter un dispendieux Multics. Je crois que vous
seriez plus à même que moi d'en raconter l'histoire.
Ce que je voulais dire c'est que Windows doit rester le plus compatible
possible dans ses diverses versions et traîne quelques boulets. Ce n'est pas
une critique du tout.

Tiens donc ! Que je sache, je peux utiliser plusieurs applications en même
temps, c'est donc bien multi-tâches. Et puis, tant que tu n'as qu'un
processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.
Ce que j'appelle multi-tâche s'applique à un OS qui sait changer de contexte
sur interruption (vieille invention de Xerox je crois) alors que W1, 2 et 3
traitaient les tâches commes des routines. Depuis W9x a su faire ainsi que
NT (qui a hérité du savoir faire d'équipes provenant de l'excellent VMS si
j'ai bonne mémoire ?). Je vous laisse la parole pour expliquer clairement
(je flatte, je flatte ...) qu'une tâche n'est pas un problème de
multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul utilisateur
donc.
Un OS comme UNIX se doit de permettre à plusieurs utilisateurs simultanés de
lancer des programmes qui peuvent eux-mêmes se dérouler en plusieurs tâches.
Je pourrais même ajouter au dessus de tout ça le multi-traitement, c'est à
dire le batch et le temps réel simultanés, le tout en multi-utilisateurs
faisant eux-même du multi-tâches.
Ca vous rappelle des souvenirs ?

En ce qui concerne donc les threads, je pense qu'il n'y a pas matière à
comparaison et que Linux comme Windows sont adapté à une informatique sur un
matériel que l'on ne pouvait pas imaginer à
l'époque de UNIX.

Sauf intérêt spécial je ne prolongerai pas ce fil.
Pardon d'avoir été un peu long et bonne fin de w.e.
Yves

Vous avez filtré cet utilisateur ! Consultez son message

AMcD®

10/10/2004 à 18:18

Yalbrieux wrote:

"AMcD®" a écrit
Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à
manipuler le MMU et la mémoire protégée. Unix a été écrit par de
pauvres gens qui n'avaient pas les moyens d'acheter un dispendieux
Multics. Je crois que vous seriez plus à même que moi d'en raconter
l'histoire.

Je ne pense pas que cela ait un quelconque rapport avec l'argent. C'est
surtout parce que MULTICS était trop lourd, ramait un max et que le projet
traînait en longueur qu'en 1969 BELL lâcha MULTICS pour GECOS7, après 4 ans
de developpement (ou 5 pour ceux qui basent le début de MULTICS en 1964). Il
te faut savoir que Thompson faisait partie du projet MULTICS. Or, comme dit
la légende, il voulait faire fonctionner un de ses anciens jeux sur les
nouvelles machines sur lesquelles il bossait en 1969, un DEC PDP-7, et
réécrivit donc un OS basé sur son ancien MULTICS. Au début, un truc très
petit, léger et même mon-utilisateur :-). Il choisit le mot UNIX pour faire
un calembour sur MULTICS. MULTICS signifiat MULTiplexed Information and
Computing Service, son nouveau système était conçu par "modules" effectuant
UNE seule "tâche" (dans le sens de service système) à la fois, d'où le terme
UNICS, changé plus tard en UNIX. Comme tu peux le voir, il se souciait bien
peu de savoir à l'époque de qui aller ou non l'utiliser, ou de question
financière, vu qu'il n'y pensait même pas ! Tu sais, l'informatique en 1969
était loin de se douter qu'on jouerait a QUAKEIII en réseau en 16M couleurs
30 ans plus tard...

Bref, UNIX est une version simplifiée et modulaire du tas de boue MULTICS,
un calembour et a été démarré pour des besoins persos. Rien à voir avec
l'argent...

Note au passage, que les Linuxiens, gens qui aiment réécrire l'histoire, qui
ont tout vu et connaissent tout, disent que UNIX est un jeu de mot sur
"eunuch" (eunuque), puisque UNIX est une version "castrée" de MULTICS en
quelque sorte. Du grand n'importe quoi, mais bon, si je devais digresser sur
le n'importe quoi chez les Linuxiens, on reviendrait aux trolls de 200
message dignes de ma grande époque ici :-).

Ce que je voulais dire c'est que Windows doit rester le plus
compatible possible dans ses diverses versions et traîne quelques
boulets. Ce n'est pas une critique du tout.

Moi si, je critique. C'est comme les processeurs et le mode V86, toujours
implémenté et parfaitement inutile. Mais bon...

Tiens donc ! Que je sache, je peux utiliser plusieurs applications
en même temps, c'est donc bien multi-tâches. Et puis, tant que tu
n'as qu'un processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.

Exactement.

Depuis W9x a su faire ainsi que NT (qui a hérité du savoir faire
d'équipes provenant de l'excellent VMS si j'ai bonne mémoire ?).

D'où la légende que si NT était fiable c'est parce que il est issu de VMS.
Du grand n'importe quoi là aussi. Évidemment que des concepts éprouvés de
VMS ont été utilisés, pourquoi se passer de choses qui fonctionnent ? Au
passage, ce ne sont pas "des" équipes, mais quelques membres, dont le
monumental Dave Cutler, qui rejoignit Kro en 1988 pour devenir chef du
developpement de NT avec je ne sais plus qui (désolé, trou de mémoire).

Je
vous laisse la parole pour expliquer clairement (je flatte, je flatte
...) qu'une tâche n'est pas un problème de multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul
utilisateur donc.

Oui, enfin, tu peux aussi avoir un serveur sous NT ou Linux hein :-). Quand
tu délivres des milleirs de requêtes par minute à 10 clients, moi, j'appelle
ça du multi-utilisateur...

Un OS comme UNIX se doit de permettre à plusieurs utilisateurs
simultanés de lancer des programmes qui peuvent eux-mêmes se dérouler
en plusieurs tâches.

???

Ca vous rappelle des souvenirs ?

Tu sais, je n'étais même pas né quand Thompson codait MULTICS hein...

--
AMcD® - Pas encore grand-père...

http://arnold.mcdonald.free.fr/

Yalbrieux wrote:

"AMcD®" <arnold.mcdonald@free.fr> a écrit

Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à
manipuler le MMU et la mémoire protégée. Unix a été écrit par de
pauvres gens qui n'avaient pas les moyens d'acheter un dispendieux
Multics. Je crois que vous seriez plus à même que moi d'en raconter
l'histoire.

Je ne pense pas que cela ait un quelconque rapport avec l'argent. C'est
surtout parce que MULTICS était trop lourd, ramait un max et que le projet
traînait en longueur qu'en 1969 BELL lâcha MULTICS pour GECOS7, après 4 ans
de developpement (ou 5 pour ceux qui basent le début de MULTICS en 1964). Il
te faut savoir que Thompson faisait partie du projet MULTICS. Or, comme dit
la légende, il voulait faire fonctionner un de ses anciens jeux sur les
nouvelles machines sur lesquelles il bossait en 1969, un DEC PDP-7, et
réécrivit donc un OS basé sur son ancien MULTICS. Au début, un truc très
petit, léger et même mon-utilisateur :-). Il choisit le mot UNIX pour faire
un calembour sur MULTICS. MULTICS signifiat MULTiplexed Information and
Computing Service, son nouveau système était conçu par "modules" effectuant
UNE seule "tâche" (dans le sens de service système) à la fois, d'où le terme
UNICS, changé plus tard en UNIX. Comme tu peux le voir, il se souciait bien
peu de savoir à l'époque de qui aller ou non l'utiliser, ou de question
financière, vu qu'il n'y pensait même pas ! Tu sais, l'informatique en 1969
était loin de se douter qu'on jouerait a QUAKEIII en réseau en 16M couleurs
30 ans plus tard...

Bref, UNIX est une version simplifiée et modulaire du tas de boue MULTICS,
un calembour et a été démarré pour des besoins persos. Rien à voir avec
l'argent...

Note au passage, que les Linuxiens, gens qui aiment réécrire l'histoire, qui
ont tout vu et connaissent tout, disent que UNIX est un jeu de mot sur
"eunuch" (eunuque), puisque UNIX est une version "castrée" de MULTICS en
quelque sorte. Du grand n'importe quoi, mais bon, si je devais digresser sur
le n'importe quoi chez les Linuxiens, on reviendrait aux trolls de 200
message dignes de ma grande époque ici :-).

Ce que je voulais dire c'est que Windows doit rester le plus
compatible possible dans ses diverses versions et traîne quelques
boulets. Ce n'est pas une critique du tout.

Moi si, je critique. C'est comme les processeurs et le mode V86, toujours
implémenté et parfaitement inutile. Mais bon...

Tiens donc ! Que je sache, je peux utiliser plusieurs applications
en même temps, c'est donc bien multi-tâches. Et puis, tant que tu
n'as qu'un processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.

Exactement.

Depuis W9x a su faire ainsi que NT (qui a hérité du savoir faire
d'équipes provenant de l'excellent VMS si j'ai bonne mémoire ?).

D'où la légende que si NT était fiable c'est parce que il est issu de VMS.
Du grand n'importe quoi là aussi. Évidemment que des concepts éprouvés de
VMS ont été utilisés, pourquoi se passer de choses qui fonctionnent ? Au
passage, ce ne sont pas "des" équipes, mais quelques membres, dont le
monumental Dave Cutler, qui rejoignit Kro en 1988 pour devenir chef du
developpement de NT avec je ne sais plus qui (désolé, trou de mémoire).

Je
vous laisse la parole pour expliquer clairement (je flatte, je flatte
...) qu'une tâche n'est pas un problème de multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul
utilisateur donc.

Oui, enfin, tu peux aussi avoir un serveur sous NT ou Linux hein :-). Quand
tu délivres des milleirs de requêtes par minute à 10 clients, moi, j'appelle
ça du multi-utilisateur...

Un OS comme UNIX se doit de permettre à plusieurs utilisateurs
simultanés de lancer des programmes qui peuvent eux-mêmes se dérouler
en plusieurs tâches.

???

Ca vous rappelle des souvenirs ?

Tu sais, je n'étais même pas né quand Thompson codait MULTICS hein...

--
AMcD® - Pas encore grand-père...

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Yalbrieux wrote:

"AMcD®" a écrit
Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à
manipuler le MMU et la mémoire protégée. Unix a été écrit par de
pauvres gens qui n'avaient pas les moyens d'acheter un dispendieux
Multics. Je crois que vous seriez plus à même que moi d'en raconter
l'histoire.

Je ne pense pas que cela ait un quelconque rapport avec l'argent. C'est
surtout parce que MULTICS était trop lourd, ramait un max et que le projet
traînait en longueur qu'en 1969 BELL lâcha MULTICS pour GECOS7, après 4 ans
de developpement (ou 5 pour ceux qui basent le début de MULTICS en 1964). Il
te faut savoir que Thompson faisait partie du projet MULTICS. Or, comme dit
la légende, il voulait faire fonctionner un de ses anciens jeux sur les
nouvelles machines sur lesquelles il bossait en 1969, un DEC PDP-7, et
réécrivit donc un OS basé sur son ancien MULTICS. Au début, un truc très
petit, léger et même mon-utilisateur :-). Il choisit le mot UNIX pour faire
un calembour sur MULTICS. MULTICS signifiat MULTiplexed Information and
Computing Service, son nouveau système était conçu par "modules" effectuant
UNE seule "tâche" (dans le sens de service système) à la fois, d'où le terme
UNICS, changé plus tard en UNIX. Comme tu peux le voir, il se souciait bien
peu de savoir à l'époque de qui aller ou non l'utiliser, ou de question
financière, vu qu'il n'y pensait même pas ! Tu sais, l'informatique en 1969
était loin de se douter qu'on jouerait a QUAKEIII en réseau en 16M couleurs
30 ans plus tard...

Bref, UNIX est une version simplifiée et modulaire du tas de boue MULTICS,
un calembour et a été démarré pour des besoins persos. Rien à voir avec
l'argent...

Note au passage, que les Linuxiens, gens qui aiment réécrire l'histoire, qui
ont tout vu et connaissent tout, disent que UNIX est un jeu de mot sur
"eunuch" (eunuque), puisque UNIX est une version "castrée" de MULTICS en
quelque sorte. Du grand n'importe quoi, mais bon, si je devais digresser sur
le n'importe quoi chez les Linuxiens, on reviendrait aux trolls de 200
message dignes de ma grande époque ici :-).

Ce que je voulais dire c'est que Windows doit rester le plus
compatible possible dans ses diverses versions et traîne quelques
boulets. Ce n'est pas une critique du tout.

Moi si, je critique. C'est comme les processeurs et le mode V86, toujours
implémenté et parfaitement inutile. Mais bon...

Tiens donc ! Que je sache, je peux utiliser plusieurs applications
en même temps, c'est donc bien multi-tâches. Et puis, tant que tu
n'as qu'un processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.

Exactement.

Depuis W9x a su faire ainsi que NT (qui a hérité du savoir faire
d'équipes provenant de l'excellent VMS si j'ai bonne mémoire ?).

D'où la légende que si NT était fiable c'est parce que il est issu de VMS.
Du grand n'importe quoi là aussi. Évidemment que des concepts éprouvés de
VMS ont été utilisés, pourquoi se passer de choses qui fonctionnent ? Au
passage, ce ne sont pas "des" équipes, mais quelques membres, dont le
monumental Dave Cutler, qui rejoignit Kro en 1988 pour devenir chef du
developpement de NT avec je ne sais plus qui (désolé, trou de mémoire).

Je
vous laisse la parole pour expliquer clairement (je flatte, je flatte
...) qu'une tâche n'est pas un problème de multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul
utilisateur donc.

Oui, enfin, tu peux aussi avoir un serveur sous NT ou Linux hein :-). Quand
tu délivres des milleirs de requêtes par minute à 10 clients, moi, j'appelle
ça du multi-utilisateur...

Un OS comme UNIX se doit de permettre à plusieurs utilisateurs
simultanés de lancer des programmes qui peuvent eux-mêmes se dérouler
en plusieurs tâches.

???

Ca vous rappelle des souvenirs ?

Tu sais, je n'étais même pas né quand Thompson codait MULTICS hein...

--
AMcD® - Pas encore grand-père...

http://arnold.mcdonald.free.fr/

Jack

11/10/2004 à 10:32

Le 10/10/2004 18:18, :

Yalbrieux wrote:

"AMcD®" a écrit

Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à
manipuler le MMU et la mémoire protégée. Unix a été écrit par de
pauvres gens qui n'avaient pas les moyens d'acheter un dispendieux
Multics. Je crois que vous seriez plus à même que moi d'en raconter
l'histoire.

Je ne pense pas que cela ait un quelconque rapport avec l'argent. C'est
surtout parce que MULTICS était trop lourd, ramait un max et que le projet
traînait en longueur qu'en 1969 BELL lâcha MULTICS pour GECOS7, après 4 ans
de developpement (ou 5 pour ceux qui basent le début de MULTICS en 1964). Il
te faut savoir que Thompson faisait partie du projet MULTICS. Or, comme dit
la légende, il voulait faire fonctionner un de ses anciens jeux sur les
nouvelles machines sur lesquelles il bossait en 1969, un DEC PDP-7, et
réécrivit donc un OS basé sur son ancien MULTICS. Au début, un truc très
petit, léger et même mon-utilisateur :-). Il choisit le mot UNIX pour faire
un calembour sur MULTICS. MULTICS signifiat MULTiplexed Information and
Computing Service, son nouveau système était conçu par "modules" effectuant
UNE seule "tâche" (dans le sens de service système) à la fois, d'où le terme
UNICS, changé plus tard en UNIX. Comme tu peux le voir, il se souciait bien
peu de savoir à l'époque de qui aller ou non l'utiliser, ou de question
financière, vu qu'il n'y pensait même pas ! Tu sais, l'informatique en 1969
était loin de se douter qu'on jouerait a QUAKEIII en réseau en 16M couleurs
30 ans plus tard...

Bref, UNIX est une version simplifiée et modulaire du tas de boue MULTICS,
un calembour et a été démarré pour des besoins persos. Rien à voir avec
l'argent...

Note au passage, que les Linuxiens, gens qui aiment réécrire l'histoire, qui
ont tout vu et connaissent tout, disent que UNIX est un jeu de mot sur
"eunuch" (eunuque), puisque UNIX est une version "castrée" de MULTICS en
quelque sorte. Du grand n'importe quoi, mais bon, si je devais digresser sur
le n'importe quoi chez les Linuxiens, on reviendrait aux trolls de 200
message dignes de ma grande époque ici :-).

Ce que je voulais dire c'est que Windows doit rester le plus
compatible possible dans ses diverses versions et traîne quelques
boulets. Ce n'est pas une critique du tout.

Moi si, je critique. C'est comme les processeurs et le mode V86, toujours
implémenté et parfaitement inutile. Mais bon...

Tiens donc ! Que je sache, je peux utiliser plusieurs applications
en même temps, c'est donc bien multi-tâches. Et puis, tant que tu
n'as qu'un processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.

Exactement.

Depuis W9x a su faire ainsi que NT (qui a hérité du savoir faire
d'équipes provenant de l'excellent VMS si j'ai bonne mémoire ?).

D'où la légende que si NT était fiable c'est parce que il est issu de VMS.
Du grand n'importe quoi là aussi. Évidemment que des concepts éprouvés de
VMS ont été utilisés, pourquoi se passer de choses qui fonctionnent ? Au
passage, ce ne sont pas "des" équipes, mais quelques membres, dont le
monumental Dave Cutler, qui rejoignit Kro en 1988 pour devenir chef du
developpement de NT avec je ne sais plus qui (désolé, trou de mémoire).

Je
vous laisse la parole pour expliquer clairement (je flatte, je flatte
...) qu'une tâche n'est pas un problème de multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul
utilisateur donc.

Oui, enfin, tu peux aussi avoir un serveur sous NT ou Linux hein :-). Quand
tu délivres des milleirs de requêtes par minute à 10 clients, moi, j'appelle
ça du multi-utilisateur...

Un OS comme UNIX se doit de permettre à plusieurs utilisateurs
simultanés de lancer des programmes qui peuvent eux-mêmes se dérouler
en plusieurs tâches.

???

Ca vous rappelle des souvenirs ?

Tu sais, je n'étais même pas né quand Thompson codait MULTICS hein...

L'abandon de Multics (chu *inconsolable*)
est peut être dû à une question pépettes (flower?).
Il ramait car les utilisateurs de Lisp (notamment) consommaient
un max de ressources.

Le 10/10/2004 18:18, :

Yalbrieux wrote:

"AMcD®" <arnold.mcdonald@free.fr> a écrit

Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à
manipuler le MMU et la mémoire protégée. Unix a été écrit par de
pauvres gens qui n'avaient pas les moyens d'acheter un dispendieux
Multics. Je crois que vous seriez plus à même que moi d'en raconter
l'histoire.

Je ne pense pas que cela ait un quelconque rapport avec l'argent. C'est
surtout parce que MULTICS était trop lourd, ramait un max et que le projet
traînait en longueur qu'en 1969 BELL lâcha MULTICS pour GECOS7, après 4 ans
de developpement (ou 5 pour ceux qui basent le début de MULTICS en 1964). Il
te faut savoir que Thompson faisait partie du projet MULTICS. Or, comme dit
la légende, il voulait faire fonctionner un de ses anciens jeux sur les
nouvelles machines sur lesquelles il bossait en 1969, un DEC PDP-7, et
réécrivit donc un OS basé sur son ancien MULTICS. Au début, un truc très
petit, léger et même mon-utilisateur :-). Il choisit le mot UNIX pour faire
un calembour sur MULTICS. MULTICS signifiat MULTiplexed Information and
Computing Service, son nouveau système était conçu par "modules" effectuant
UNE seule "tâche" (dans le sens de service système) à la fois, d'où le terme
UNICS, changé plus tard en UNIX. Comme tu peux le voir, il se souciait bien
peu de savoir à l'époque de qui aller ou non l'utiliser, ou de question
financière, vu qu'il n'y pensait même pas ! Tu sais, l'informatique en 1969
était loin de se douter qu'on jouerait a QUAKEIII en réseau en 16M couleurs
30 ans plus tard...

Bref, UNIX est une version simplifiée et modulaire du tas de boue MULTICS,
un calembour et a été démarré pour des besoins persos. Rien à voir avec
l'argent...

Note au passage, que les Linuxiens, gens qui aiment réécrire l'histoire, qui
ont tout vu et connaissent tout, disent que UNIX est un jeu de mot sur
"eunuch" (eunuque), puisque UNIX est une version "castrée" de MULTICS en
quelque sorte. Du grand n'importe quoi, mais bon, si je devais digresser sur
le n'importe quoi chez les Linuxiens, on reviendrait aux trolls de 200
message dignes de ma grande époque ici :-).

Ce que je voulais dire c'est que Windows doit rester le plus
compatible possible dans ses diverses versions et traîne quelques
boulets. Ce n'est pas une critique du tout.

Moi si, je critique. C'est comme les processeurs et le mode V86, toujours
implémenté et parfaitement inutile. Mais bon...

Tiens donc ! Que je sache, je peux utiliser plusieurs applications
en même temps, c'est donc bien multi-tâches. Et puis, tant que tu
n'as qu'un processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.

Exactement.

Depuis W9x a su faire ainsi que NT (qui a hérité du savoir faire
d'équipes provenant de l'excellent VMS si j'ai bonne mémoire ?).

D'où la légende que si NT était fiable c'est parce que il est issu de VMS.
Du grand n'importe quoi là aussi. Évidemment que des concepts éprouvés de
VMS ont été utilisés, pourquoi se passer de choses qui fonctionnent ? Au
passage, ce ne sont pas "des" équipes, mais quelques membres, dont le
monumental Dave Cutler, qui rejoignit Kro en 1988 pour devenir chef du
developpement de NT avec je ne sais plus qui (désolé, trou de mémoire).

Je
vous laisse la parole pour expliquer clairement (je flatte, je flatte
...) qu'une tâche n'est pas un problème de multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul
utilisateur donc.

Oui, enfin, tu peux aussi avoir un serveur sous NT ou Linux hein :-). Quand
tu délivres des milleirs de requêtes par minute à 10 clients, moi, j'appelle
ça du multi-utilisateur...

Un OS comme UNIX se doit de permettre à plusieurs utilisateurs
simultanés de lancer des programmes qui peuvent eux-mêmes se dérouler
en plusieurs tâches.

???

Ca vous rappelle des souvenirs ?

Tu sais, je n'étais même pas né quand Thompson codait MULTICS hein...

L'abandon de Multics (chu *inconsolable*)
est peut être dû à une question pépettes (flower?).
Il ramait car les utilisateurs de Lisp (notamment) consommaient
un max de ressources.

Vous avez filtré cet utilisateur ! Consultez son message

Le 10/10/2004 18:18, :

Yalbrieux wrote:

"AMcD®" a écrit

Unix et cie sont bien plus vieux que Windows.

Bien sûr ! Vous souvenez-vous de Multics ? Ce fut le premier à
manipuler le MMU et la mémoire protégée. Unix a été écrit par de
pauvres gens qui n'avaient pas les moyens d'acheter un dispendieux
Multics. Je crois que vous seriez plus à même que moi d'en raconter
l'histoire.

Je ne pense pas que cela ait un quelconque rapport avec l'argent. C'est
surtout parce que MULTICS était trop lourd, ramait un max et que le projet
traînait en longueur qu'en 1969 BELL lâcha MULTICS pour GECOS7, après 4 ans
de developpement (ou 5 pour ceux qui basent le début de MULTICS en 1964). Il
te faut savoir que Thompson faisait partie du projet MULTICS. Or, comme dit
la légende, il voulait faire fonctionner un de ses anciens jeux sur les
nouvelles machines sur lesquelles il bossait en 1969, un DEC PDP-7, et
réécrivit donc un OS basé sur son ancien MULTICS. Au début, un truc très
petit, léger et même mon-utilisateur :-). Il choisit le mot UNIX pour faire
un calembour sur MULTICS. MULTICS signifiat MULTiplexed Information and
Computing Service, son nouveau système était conçu par "modules" effectuant
UNE seule "tâche" (dans le sens de service système) à la fois, d'où le terme
UNICS, changé plus tard en UNIX. Comme tu peux le voir, il se souciait bien
peu de savoir à l'époque de qui aller ou non l'utiliser, ou de question
financière, vu qu'il n'y pensait même pas ! Tu sais, l'informatique en 1969
était loin de se douter qu'on jouerait a QUAKEIII en réseau en 16M couleurs
30 ans plus tard...

Bref, UNIX est une version simplifiée et modulaire du tas de boue MULTICS,
un calembour et a été démarré pour des besoins persos. Rien à voir avec
l'argent...

Note au passage, que les Linuxiens, gens qui aiment réécrire l'histoire, qui
ont tout vu et connaissent tout, disent que UNIX est un jeu de mot sur
"eunuch" (eunuque), puisque UNIX est une version "castrée" de MULTICS en
quelque sorte. Du grand n'importe quoi, mais bon, si je devais digresser sur
le n'importe quoi chez les Linuxiens, on reviendrait aux trolls de 200
message dignes de ma grande époque ici :-).

Ce que je voulais dire c'est que Windows doit rester le plus
compatible possible dans ses diverses versions et traîne quelques
boulets. Ce n'est pas une critique du tout.

Moi si, je critique. C'est comme les processeurs et le mode V86, toujours
implémenté et parfaitement inutile. Mais bon...

Tiens donc ! Que je sache, je peux utiliser plusieurs applications
en même temps, c'est donc bien multi-tâches. Et puis, tant que tu
n'as qu'un processeur...

Oui. Il faudrait aussi s'entendre sur le vocabulaire.

Exactement.

Depuis W9x a su faire ainsi que NT (qui a hérité du savoir faire
d'équipes provenant de l'excellent VMS si j'ai bonne mémoire ?).

D'où la légende que si NT était fiable c'est parce que il est issu de VMS.
Du grand n'importe quoi là aussi. Évidemment que des concepts éprouvés de
VMS ont été utilisés, pourquoi se passer de choses qui fonctionnent ? Au
passage, ce ne sont pas "des" équipes, mais quelques membres, dont le
monumental Dave Cutler, qui rejoignit Kro en 1988 pour devenir chef du
developpement de NT avec je ne sais plus qui (désolé, trou de mémoire).

Je
vous laisse la parole pour expliquer clairement (je flatte, je flatte
...) qu'une tâche n'est pas un problème de multi-processeurs.
Windows et Linux s'occupent d'ordinateur personnel, avec un seul
utilisateur donc.

Oui, enfin, tu peux aussi avoir un serveur sous NT ou Linux hein :-). Quand
tu délivres des milleirs de requêtes par minute à 10 clients, moi, j'appelle
ça du multi-utilisateur...

Un OS comme UNIX se doit de permettre à plusieurs utilisateurs
simultanés de lancer des programmes qui peuvent eux-mêmes se dérouler
en plusieurs tâches.

???

Ca vous rappelle des souvenirs ?

Tu sais, je n'étais même pas né quand Thompson codait MULTICS hein...

L'abandon de Multics (chu *inconsolable*)
est peut être dû à une question pépettes (flower?).
Il ramait car les utilisateurs de Lisp (notamment) consommaient
un max de ressources.

AMcD®

11/10/2004 à 17:09

Jack wrote:

L'abandon de Multics (chu *inconsolable*)
est peut être dû à une question pépettes (flower?).

Arf, qui voilà :-). Me dis pas que t'as connu/utilisé MULTICS en 1965 quand
même ? Tiens, au fait, un site pas mal à lire :

http://www.multicians.org/history.html

En fouillant dessus, tu trouves :

"When we actually started building and integrating the system, we discovered
that some of the MSPM designs were far too complex" [1]

"In 1968-69 the system was late and under significant financial pressure and
threat of cancellation"

"Over time, hope was replaced by frustration as the group effort initially
failed to produce an economically useful system. Bell Labs withdrew from the
effort in 1969 but a small band of users at Bell Labs Computing Science
Research Center in Murray Hill ". [2]

"... the problem was the increasing obviousness of the failure of Multics to
deliver promptly any sort of usable system, let alone the panacea envisioned
earlier"

En fait, c'était ce qu'on appelerait aujourd'hui un véritable tas de boue.
Très complexe, long à développer et à stabiliser.

Par contre, je croyais que MULTICS avait cessé tout battement respiratoire
vers 1985, en fait, je viens de voir qu'il vécu une quinzaine d'années
encore !

Il ramait car les utilisateurs de Lisp (notamment) consommaient
un max de ressources.

Faire du LISP sur MULTICS, tu m'étonnes que ça ramait 8-| !

[1] Multics System Programmer's Manual.
[2] Dont les célèbres Ken Thompson et Dennis Ritchie.

--
AMcD®

http://arnold.mcdonald.free.fr/

Aurelien REGAT-BARREL

12/10/2004 à 23:35

> Quelqu'un pourrait-il me dire la pertinence de la présence des
EnterCriticalSection pour ce bout de code, dans la mesure où je ne crois
pas
que l'on exploite des données communes à tous les threads mais un id du
thread concerné que l'on imprime à l'écran.

Si tu parles de ça :
http://bob.developpez.com/tutapiwin/projets/projet09.zip
Le but est surtout didactique il me semble, et normalement (j'ai pas testé)
chaque thread devrait faire un Sleep(500) l'un après l'autre au lieu d'avoir
les 5 thread qui font leur Sleep en même temps. Remplace Sleep(500) par un
traitement sur une ressource partagée...

--
Aurélien REGAT-BARREL

Aurelien REGAT-BARREL

13/10/2004 à 00:10

> Pas de fork sous windows.

N'est-ce pas plutôt pas de fork sous Win32 ?
Il me semble que le kernel NT supporte le fork et que c'est utilisé par le
sous système POSIX et Interix (ce qui le distingue de Cygwin qui l'émule en
user mode).

--
Aurélien REGAT-BARREL

Cyrille Szymanski

13/10/2004 à 00:33

Le 12-10-2004, Aurelien REGAT-BARREL
a écrit :

Pas de fork sous windows.

N'est-ce pas plutôt pas de fork sous Win32 ? Il me semble que le
kernel NT supporte le fork et que c'est utilisé par le sous système
POSIX et Interix (ce qui le distingue de Cygwin qui l'émule en user
mode).

Je coupe court à tout débat : si tu lis les autres messages de ce fil,
tu te rendras compte qu'il faut comprendre "ne pas faire de fork()
sous windows" et non "on ne peut pas faire de fork()".

--
cns

fonction fork() sous windows...

10 réponses

Veuillez sélectionner un problème