> En quoi le fait qu'il y ait une centaine de threads
> peut-il conduire à la sous utilisation d'au plus une huitaine de
> processeurs?
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
Tu peux aussi réinventer l'eau chaude à chaque fois que tu prends
une douche. Enfin, pourquoi faire simple quand on peut faire
compliqué...
JKB
> En quoi le fait qu'il y ait une centaine de threads
> peut-il conduire à la sous utilisation d'au plus une huitaine de
> processeurs?
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
Tu peux aussi réinventer l'eau chaude à chaque fois que tu prends
une douche. Enfin, pourquoi faire simple quand on peut faire
compliqué...
JKB
> En quoi le fait qu'il y ait une centaine de threads
> peut-il conduire à la sous utilisation d'au plus une huitaine de
> processeurs?
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
Tu peux aussi réinventer l'eau chaude à chaque fois que tu prends
une douche. Enfin, pourquoi faire simple quand on peut faire
compliqué...
JKB
:-(
http://linux-attitude.fr/post/processus-et-threads
Un thread, c'est un découpage d'un processus. Cela veut dire qu'il
utilise exactement la même mémoire qu'un processus, ainsi que les
mêmes descripteurs de fichiers
ou tu as vue qu'un processus devait savoir si il était dans le swap
:-(
http://linux-attitude.fr/post/processus-et-threads
Un thread, c'est un découpage d'un processus. Cela veut dire qu'il
utilise exactement la même mémoire qu'un processus, ainsi que les
mêmes descripteurs de fichiers
ou tu as vue qu'un processus devait savoir si il était dans le swap
:-(
http://linux-attitude.fr/post/processus-et-threads
Un thread, c'est un découpage d'un processus. Cela veut dire qu'il
utilise exactement la même mémoire qu'un processus, ainsi que les
mêmes descripteurs de fichiers
ou tu as vue qu'un processus devait savoir si il était dans le swap
JKB wrote:> En quoi le fait qu'il y ait une centaine de threads
> peut-il conduire à la sous utilisation d'au plus une huitaine de
> processeurs?
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
Je ne comprends rien, tous les threads voient la *même* mémoire commune
(sauf le "thread local storage") donc à priori les 8 threads n'utilisent
que 8 Go de mémoire. Qu'il faille protéger par des mutex des parties de
ces 8 Go pour que les accés des threads ne se marchent pas sur les pieds
est une autre chose. Ou alors tu fais tout ton calcul en local dans chaque
thread, ce qui est grosso modo le moyen de ne pas bénéficier de la
mémoire partagée. Autant faire les calculs dans des processus
indépendants et communiquer par pipe!
Tu peux aussi réinventer l'eau chaude à chaque fois que tu prends
une douche. Enfin, pourquoi faire simple quand on peut faire
compliqué...
Compliqué, tu veux rire, c'est de l'ordre de 10 lignes de C que tu peux
mettre dans une fonction au début de ton programme. Une variable qu'on
peut incrémenter ou décrémenter (les opérations de sémaphore) protégée
par un mutex, et une variable de condition qui teste si cette variable
est nulle, voilà l'alpha et l'omega de cette affaire.
JKB <jkb@koenigsberg.invalid> wrote:
> En quoi le fait qu'il y ait une centaine de threads
> peut-il conduire à la sous utilisation d'au plus une huitaine de
> processeurs?
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
Je ne comprends rien, tous les threads voient la *même* mémoire commune
(sauf le "thread local storage") donc à priori les 8 threads n'utilisent
que 8 Go de mémoire. Qu'il faille protéger par des mutex des parties de
ces 8 Go pour que les accés des threads ne se marchent pas sur les pieds
est une autre chose. Ou alors tu fais tout ton calcul en local dans chaque
thread, ce qui est grosso modo le moyen de ne pas bénéficier de la
mémoire partagée. Autant faire les calculs dans des processus
indépendants et communiquer par pipe!
Tu peux aussi réinventer l'eau chaude à chaque fois que tu prends
une douche. Enfin, pourquoi faire simple quand on peut faire
compliqué...
Compliqué, tu veux rire, c'est de l'ordre de 10 lignes de C que tu peux
mettre dans une fonction au début de ton programme. Une variable qu'on
peut incrémenter ou décrémenter (les opérations de sémaphore) protégée
par un mutex, et une variable de condition qui teste si cette variable
est nulle, voilà l'alpha et l'omega de cette affaire.
JKB wrote:> En quoi le fait qu'il y ait une centaine de threads
> peut-il conduire à la sous utilisation d'au plus une huitaine de
> processeurs?
Imagine qu'à un moment, chacun de tes threads travaille sur 8 Go de
Je ne comprends rien, tous les threads voient la *même* mémoire commune
(sauf le "thread local storage") donc à priori les 8 threads n'utilisent
que 8 Go de mémoire. Qu'il faille protéger par des mutex des parties de
ces 8 Go pour que les accés des threads ne se marchent pas sur les pieds
est une autre chose. Ou alors tu fais tout ton calcul en local dans chaque
thread, ce qui est grosso modo le moyen de ne pas bénéficier de la
mémoire partagée. Autant faire les calculs dans des processus
indépendants et communiquer par pipe!
Tu peux aussi réinventer l'eau chaude à chaque fois que tu prends
une douche. Enfin, pourquoi faire simple quand on peut faire
compliqué...
Compliqué, tu veux rire, c'est de l'ordre de 10 lignes de C que tu peux
mettre dans une fonction au début de ton programme. Une variable qu'on
peut incrémenter ou décrémenter (les opérations de sémaphore) protégée
par un mutex, et une variable de condition qui teste si cette variable
est nulle, voilà l'alpha et l'omega de cette affaire.
> :-(
>http://linux-attitude.fr/post/processus-et-threads
> Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
> utilise exactement la m me m moire qu'un processus, ainsi que les
> m mes descripteurs de fichiers
Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
leur coin.
> ou tu as vue qu'un processus devait savoir si il tait dans le swap
Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
il vaut mieux viter de laisser tous les traitements se faire en
parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
6 calculs en cours un moment donn , sinon le syst me commence
utiliser la partition d' change au lieu de tout faire en m moire.
> :-(
>http://linux-attitude.fr/post/processus-et-threads
> Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
> utilise exactement la m me m moire qu'un processus, ainsi que les
> m mes descripteurs de fichiers
Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
leur coin.
> ou tu as vue qu'un processus devait savoir si il tait dans le swap
Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
il vaut mieux viter de laisser tous les traitements se faire en
parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
6 calculs en cours un moment donn , sinon le syst me commence
utiliser la partition d' change au lieu de tout faire en m moire.
> :-(
>http://linux-attitude.fr/post/processus-et-threads
> Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
> utilise exactement la m me m moire qu'un processus, ainsi que les
> m mes descripteurs de fichiers
Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
leur coin.
> ou tu as vue qu'un processus devait savoir si il tait dans le swap
Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
il vaut mieux viter de laisser tous les traitements se faire en
parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
6 calculs en cours un moment donn , sinon le syst me commence
utiliser la partition d' change au lieu de tout faire en m moire.
On 22 déc, 17:29, Yliur wrote:> :-(
>http://linux-attitude.fr/post/processus-et-threads
> Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
> utilise exactement la m me m moire qu'un processus, ainsi que les
> m mes descripteurs de fichiers
Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
leur coin.
> ou tu as vue qu'un processus devait savoir si il tait dans le swap
Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
il vaut mieux viter de laisser tous les traitements se faire en
parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
6 calculs en cours un moment donn , sinon le syst me commence
utiliser la partition d' change au lieu de tout faire en m moire.
mais non il c'est juste mélanger les pinceaux et il ne veut pas le
reconnaitre et je le taquine c'est tout
On 22 déc, 17:29, Yliur <yl...@free.fr> wrote:
> :-(
>http://linux-attitude.fr/post/processus-et-threads
> Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
> utilise exactement la m me m moire qu'un processus, ainsi que les
> m mes descripteurs de fichiers
Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
leur coin.
> ou tu as vue qu'un processus devait savoir si il tait dans le swap
Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
il vaut mieux viter de laisser tous les traitements se faire en
parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
6 calculs en cours un moment donn , sinon le syst me commence
utiliser la partition d' change au lieu de tout faire en m moire.
mais non il c'est juste mélanger les pinceaux et il ne veut pas le
reconnaitre et je le taquine c'est tout
On 22 déc, 17:29, Yliur wrote:> :-(
>http://linux-attitude.fr/post/processus-et-threads
> Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
> utilise exactement la m me m moire qu'un processus, ainsi que les
> m mes descripteurs de fichiers
Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
leur coin.
> ou tu as vue qu'un processus devait savoir si il tait dans le swap
Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
il vaut mieux viter de laisser tous les traitements se faire en
parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
6 calculs en cours un moment donn , sinon le syst me commence
utiliser la partition d' change au lieu de tout faire en m moire.
mais non il c'est juste mélanger les pinceaux et il ne veut pas le
reconnaitre et je le taquine c'est tout
Je repose donc la question : pourquoi veux-tu absolument utiliser
des fonctions de dix lignes alors qu'un simple appel à un sémaphore
suffit.
Je repose donc la question : pourquoi veux-tu absolument utiliser
des fonctions de dix lignes alors qu'un simple appel à un sémaphore
suffit.
Je repose donc la question : pourquoi veux-tu absolument utiliser
des fonctions de dix lignes alors qu'un simple appel à un sémaphore
suffit.
Le Wed, 22 Dec 2010 09:22:16 -0800 (PST),
remy écrivait :
> On 22 déc, 17:29, Yliur wrote:
>> > :-(
>> >http://linux-attitude.fr/post/processus-et-threads
>> > Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
>> > utilise exactement la m me m moire qu'un processus, ainsi que les
>> > m mes descripteurs de fichiers
>> Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
>> S'ils font deux calculs s par s, ils traitent chacun leurs donn es dan s
>> leur coin.
>> > ou tu as vue qu'un processus devait savoir si il tait dans le swa p
>> Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
>> m moire que pour lancer 6 requ tes simultan es et que tu as 15 demande s
>> il vaut mieux viter de laisser tous les traitements se faire en
>> parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
>> 6 calculs en cours un moment donn , sinon le syst me commence
>> utiliser la partition d' change au lieu de tout faire en m moire.
> mais non il c'est juste mélanger les pinceaux et il ne veut pas le
> reconnaitre et je le taquine c'est tout
Tu ne taquines strictement rien. Tu viens juste comme à ton habitude
de raconter une grosse conceté. N'essaye pas de te racc rocher aux
branches. Un processus n'utilise le swap qu'à partir du moment où il
y a un défaut de page _et_ plus de page disponible en R AM. Si tu te
démerdes pour que toutes tes données tiennent en mé moire, il n'y a
aucune raison de commencer à swapper. C'est donc à to i de limiter
avec un sémaphore l'occupation de la mémoire pour é viter d'utiliser
le swap.
Ça veux dire deux choses : que tu comprennes ce qu'est un processus,
ce qu'est un thread (et que tu admettes que tu peux avoir dans deux
threads du même espace mémoire des données qui ne s ont pas
partagées) et surtout comment tout ce beau monde est g éré.
Je crois que tu as encore un peu de boulot.
Le Wed, 22 Dec 2010 09:22:16 -0800 (PST),
remy <remy.aumeun...@libertysurf.fr> écrivait :
> On 22 déc, 17:29, Yliur <yl...@free.fr> wrote:
>> > :-(
>> >http://linux-attitude.fr/post/processus-et-threads
>> > Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
>> > utilise exactement la m me m moire qu'un processus, ainsi que les
>> > m mes descripteurs de fichiers
>> Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
>> S'ils font deux calculs s par s, ils traitent chacun leurs donn es dan s
>> leur coin.
>> > ou tu as vue qu'un processus devait savoir si il tait dans le swa p
>> Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
>> m moire que pour lancer 6 requ tes simultan es et que tu as 15 demande s
>> il vaut mieux viter de laisser tous les traitements se faire en
>> parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
>> 6 calculs en cours un moment donn , sinon le syst me commence
>> utiliser la partition d' change au lieu de tout faire en m moire.
> mais non il c'est juste mélanger les pinceaux et il ne veut pas le
> reconnaitre et je le taquine c'est tout
Tu ne taquines strictement rien. Tu viens juste comme à ton habitude
de raconter une grosse conceté. N'essaye pas de te racc rocher aux
branches. Un processus n'utilise le swap qu'à partir du moment où il
y a un défaut de page _et_ plus de page disponible en R AM. Si tu te
démerdes pour que toutes tes données tiennent en mé moire, il n'y a
aucune raison de commencer à swapper. C'est donc à to i de limiter
avec un sémaphore l'occupation de la mémoire pour é viter d'utiliser
le swap.
Ça veux dire deux choses : que tu comprennes ce qu'est un processus,
ce qu'est un thread (et que tu admettes que tu peux avoir dans deux
threads du même espace mémoire des données qui ne s ont pas
partagées) et surtout comment tout ce beau monde est g éré.
Je crois que tu as encore un peu de boulot.
Le Wed, 22 Dec 2010 09:22:16 -0800 (PST),
remy écrivait :
> On 22 déc, 17:29, Yliur wrote:
>> > :-(
>> >http://linux-attitude.fr/post/processus-et-threads
>> > Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
>> > utilise exactement la m me m moire qu'un processus, ainsi que les
>> > m mes descripteurs de fichiers
>> Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
>> S'ils font deux calculs s par s, ils traitent chacun leurs donn es dan s
>> leur coin.
>> > ou tu as vue qu'un processus devait savoir si il tait dans le swa p
>> Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
>> m moire que pour lancer 6 requ tes simultan es et que tu as 15 demande s
>> il vaut mieux viter de laisser tous les traitements se faire en
>> parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
>> 6 calculs en cours un moment donn , sinon le syst me commence
>> utiliser la partition d' change au lieu de tout faire en m moire.
> mais non il c'est juste mélanger les pinceaux et il ne veut pas le
> reconnaitre et je le taquine c'est tout
Tu ne taquines strictement rien. Tu viens juste comme à ton habitude
de raconter une grosse conceté. N'essaye pas de te racc rocher aux
branches. Un processus n'utilise le swap qu'à partir du moment où il
y a un défaut de page _et_ plus de page disponible en R AM. Si tu te
démerdes pour que toutes tes données tiennent en mé moire, il n'y a
aucune raison de commencer à swapper. C'est donc à to i de limiter
avec un sémaphore l'occupation de la mémoire pour é viter d'utiliser
le swap.
Ça veux dire deux choses : que tu comprennes ce qu'est un processus,
ce qu'est un thread (et que tu admettes que tu peux avoir dans deux
threads du même espace mémoire des données qui ne s ont pas
partagées) et surtout comment tout ce beau monde est g éré.
Je crois que tu as encore un peu de boulot.
On 22 déc, 18:30, JKB wrote:Le Wed, 22 Dec 2010 09:22:16 -0800 (PST),
remy écrivait :
> On 22 déc, 17:29, Yliur wrote:
>> > :-(
>> >http://linux-attitude.fr/post/processus-et-threads
>> > Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
>> > utilise exactement la m me m moire qu'un processus, ainsi que les
>> > m mes descripteurs de fichiers
>> Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
>> S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
>> leur coin.
>> > ou tu as vue qu'un processus devait savoir si il tait dans le swap
>> Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
>> m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
>> il vaut mieux viter de laisser tous les traitements se faire en
>> parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
>> 6 calculs en cours un moment donn , sinon le syst me commence
>> utiliser la partition d' change au lieu de tout faire en m moire.
> mais non il c'est juste mélanger les pinceaux et il ne veut pas le
> reconnaitre et je le taquine c'est tout
Tu ne taquines strictement rien. Tu viens juste comme à ton habitude
de raconter une grosse conceté. N'essaye pas de te raccrocher aux
branches. Un processus n'utilise le swap qu'à partir du moment où il
y a un défaut de page _et_ plus de page disponible en RAM. Si tu te
démerdes pour que toutes tes données tiennent en mémoire, il n'y a
aucune raison de commencer à swapper. C'est donc à toi de limiter
avec un sémaphore l'occupation de la mémoire pour éviter d'utiliser
le swap.
Ça veux dire deux choses : que tu comprennes ce qu'est un processus,
ce qu'est un thread (et que tu admettes que tu peux avoir dans deux
threads du même espace mémoire des données qui ne sont pas
partagées) et surtout comment tout ce beau monde est géré.
cela implique que tu fais de la gestion dynamique des threads en
fonction de la mémoire dispo donc tu as un tas géré à la mimine
rien ne t'empêche de suspendre les threads avec un mutex
maintenant tu peux aussi le faire avec des sémaphores les goûts et
les
couleurs hein,
tu es encore dans les 0.1 % de cas a la con
mais ce n'est pas bloquant que tu le veuilles ou pas
Je crois que tu as encore un peu de boulot.
mais oui,n'hésite pas
On 22 déc, 18:30, JKB <j...@koenigsberg.invalid> wrote:
Le Wed, 22 Dec 2010 09:22:16 -0800 (PST),
remy <remy.aumeun...@libertysurf.fr> écrivait :
> On 22 déc, 17:29, Yliur <yl...@free.fr> wrote:
>> > :-(
>> >http://linux-attitude.fr/post/processus-et-threads
>> > Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
>> > utilise exactement la m me m moire qu'un processus, ainsi que les
>> > m mes descripteurs de fichiers
>> Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
>> S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
>> leur coin.
>> > ou tu as vue qu'un processus devait savoir si il tait dans le swap
>> Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
>> m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
>> il vaut mieux viter de laisser tous les traitements se faire en
>> parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
>> 6 calculs en cours un moment donn , sinon le syst me commence
>> utiliser la partition d' change au lieu de tout faire en m moire.
> mais non il c'est juste mélanger les pinceaux et il ne veut pas le
> reconnaitre et je le taquine c'est tout
Tu ne taquines strictement rien. Tu viens juste comme à ton habitude
de raconter une grosse conceté. N'essaye pas de te raccrocher aux
branches. Un processus n'utilise le swap qu'à partir du moment où il
y a un défaut de page _et_ plus de page disponible en RAM. Si tu te
démerdes pour que toutes tes données tiennent en mémoire, il n'y a
aucune raison de commencer à swapper. C'est donc à toi de limiter
avec un sémaphore l'occupation de la mémoire pour éviter d'utiliser
le swap.
Ça veux dire deux choses : que tu comprennes ce qu'est un processus,
ce qu'est un thread (et que tu admettes que tu peux avoir dans deux
threads du même espace mémoire des données qui ne sont pas
partagées) et surtout comment tout ce beau monde est géré.
cela implique que tu fais de la gestion dynamique des threads en
fonction de la mémoire dispo donc tu as un tas géré à la mimine
rien ne t'empêche de suspendre les threads avec un mutex
maintenant tu peux aussi le faire avec des sémaphores les goûts et
les
couleurs hein,
tu es encore dans les 0.1 % de cas a la con
mais ce n'est pas bloquant que tu le veuilles ou pas
Je crois que tu as encore un peu de boulot.
mais oui,n'hésite pas
On 22 déc, 18:30, JKB wrote:Le Wed, 22 Dec 2010 09:22:16 -0800 (PST),
remy écrivait :
> On 22 déc, 17:29, Yliur wrote:
>> > :-(
>> >http://linux-attitude.fr/post/processus-et-threads
>> > Un thread, c'est un d coupage d'un processus. Cela veut dire qu'il
>> > utilise exactement la m me m moire qu'un processus, ainsi que les
>> > m mes descripteurs de fichiers
>> Le fil d'ex cution peut ou non partager ses donn es avec le voisin.
>> S'ils font deux calculs s par s, ils traitent chacun leurs donn es dans
>> leur coin.
>> > ou tu as vue qu'un processus devait savoir si il tait dans le swap
>> Il n'a pas dit qu'il devait le savoir mais que si tu n'as de
>> m moire que pour lancer 6 requ tes simultan es et que tu as 15 demandes
>> il vaut mieux viter de laisser tous les traitements se faire en
>> parall le et en s rialiser certains. S'assurer qu'il n'y a pas plus de
>> 6 calculs en cours un moment donn , sinon le syst me commence
>> utiliser la partition d' change au lieu de tout faire en m moire.
> mais non il c'est juste mélanger les pinceaux et il ne veut pas le
> reconnaitre et je le taquine c'est tout
Tu ne taquines strictement rien. Tu viens juste comme à ton habitude
de raconter une grosse conceté. N'essaye pas de te raccrocher aux
branches. Un processus n'utilise le swap qu'à partir du moment où il
y a un défaut de page _et_ plus de page disponible en RAM. Si tu te
démerdes pour que toutes tes données tiennent en mémoire, il n'y a
aucune raison de commencer à swapper. C'est donc à toi de limiter
avec un sémaphore l'occupation de la mémoire pour éviter d'utiliser
le swap.
Ça veux dire deux choses : que tu comprennes ce qu'est un processus,
ce qu'est un thread (et que tu admettes que tu peux avoir dans deux
threads du même espace mémoire des données qui ne sont pas
partagées) et surtout comment tout ce beau monde est géré.
cela implique que tu fais de la gestion dynamique des threads en
fonction de la mémoire dispo donc tu as un tas géré à la mimine
rien ne t'empêche de suspendre les threads avec un mutex
maintenant tu peux aussi le faire avec des sémaphores les goûts et
les
couleurs hein,
tu es encore dans les 0.1 % de cas a la con
mais ce n'est pas bloquant que tu le veuilles ou pas
Je crois que tu as encore un peu de boulot.
mais oui,n'hésite pas
Je ne comprend pas pourquoi la traduction (voire la version
originale) n'emploie pas le terme de driver/pilote pour les
translators/traducteurs, puisqu'ils sont des serveurs servant à ça.
Ou alors j'ai rien compris ^^
?
Là il faut faire appel à un plus grand spécialiste des
(micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
tout hasard...
Sinon les traducteurs ne sont pas forcément des pilotes pour le
matériel, ils servent à représenter quelque chose sous la forme d'un
système de fichier (si je ne dis pas de bêtises). Par exemple on peut
avoir un traducteur représentant l'arbre des discussions de ce groupe
sous forme d'un ensemble de fichiers/répertoire.
Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philosophie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciaux tels les
périphériques. Finalement, tout ce monde est en mode utilisateur,
et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, changer chaque
partie du système sans droits particuliers, et sans reboot. On peut même
enchaîner les micro-noyaux ^^.
Mais une question reste sans réponse, il puisqu'il y a des personnes qualifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuelle des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimisée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare de type
386 trainée comme un boulet ?
Je ne comprend pas pourquoi la traduction (voire la version
originale) n'emploie pas le terme de driver/pilote pour les
translators/traducteurs, puisqu'ils sont des serveurs servant à ça.
Ou alors j'ai rien compris ^^
?
Là il faut faire appel à un plus grand spécialiste des
(micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
tout hasard...
Sinon les traducteurs ne sont pas forcément des pilotes pour le
matériel, ils servent à représenter quelque chose sous la forme d'un
système de fichier (si je ne dis pas de bêtises). Par exemple on peut
avoir un traducteur représentant l'arbre des discussions de ce groupe
sous forme d'un ensemble de fichiers/répertoire.
Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philosophie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciaux tels les
périphériques. Finalement, tout ce monde est en mode utilisateur,
et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, changer chaque
partie du système sans droits particuliers, et sans reboot. On peut même
enchaîner les micro-noyaux ^^.
Mais une question reste sans réponse, il puisqu'il y a des personnes qualifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuelle des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimisée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare de type
386 trainée comme un boulet ?
Je ne comprend pas pourquoi la traduction (voire la version
originale) n'emploie pas le terme de driver/pilote pour les
translators/traducteurs, puisqu'ils sont des serveurs servant à ça.
Ou alors j'ai rien compris ^^
?
Là il faut faire appel à un plus grand spécialiste des
(micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
tout hasard...
Sinon les traducteurs ne sont pas forcément des pilotes pour le
matériel, ils servent à représenter quelque chose sous la forme d'un
système de fichier (si je ne dis pas de bêtises). Par exemple on peut
avoir un traducteur représentant l'arbre des discussions de ce groupe
sous forme d'un ensemble de fichiers/répertoire.
Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philosophie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciaux tels les
périphériques. Finalement, tout ce monde est en mode utilisateur,
et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, changer chaque
partie du système sans droits particuliers, et sans reboot. On peut même
enchaîner les micro-noyaux ^^.
Mais une question reste sans réponse, il puisqu'il y a des personnes qualifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuelle des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimisée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare de type
386 trainée comme un boulet ?
>> Je ne comprend pas pourquoi la traduction (voire la version
>> originale) n'emploie pas le terme de driver/pilote pour les
>> translators/traducteurs, puisqu'ils sont des serveurs servant à ça .
>> Ou alors j'ai rien compris ^^
> ?
> Là il faut faire appel à un plus grand spécialiste des
> (micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
> tout hasard...
> Sinon les traducteurs ne sont pas forcément des pilotes pour le
> matériel, ils servent à représenter quelque chose sous la forme d 'un
> système de fichier (si je ne dis pas de bêtises). Par exemple on pe ut
> avoir un traducteur représentant l'arbre des discussions de ce groupe
> sous forme d'un ensemble de fichiers/répertoire.
Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philoso phie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciau x tels les
périphériques. Finalement, tout ce monde est en mode utilisateur, et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, chang er chaque
partie du système sans droits particuliers, et sans reboot. On peut m ême
enchaîner les micro-noyaux ^^.
Mais une question reste sans réponse, il puisqu'il y a des personnes qu alifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuell e des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimis ée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare d e type
386 trainée comme un boulet ?
>> Je ne comprend pas pourquoi la traduction (voire la version
>> originale) n'emploie pas le terme de driver/pilote pour les
>> translators/traducteurs, puisqu'ils sont des serveurs servant à ça .
>> Ou alors j'ai rien compris ^^
> ?
> Là il faut faire appel à un plus grand spécialiste des
> (micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
> tout hasard...
> Sinon les traducteurs ne sont pas forcément des pilotes pour le
> matériel, ils servent à représenter quelque chose sous la forme d 'un
> système de fichier (si je ne dis pas de bêtises). Par exemple on pe ut
> avoir un traducteur représentant l'arbre des discussions de ce groupe
> sous forme d'un ensemble de fichiers/répertoire.
Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philoso phie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciau x tels les
périphériques. Finalement, tout ce monde est en mode utilisateur, et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, chang er chaque
partie du système sans droits particuliers, et sans reboot. On peut m ême
enchaîner les micro-noyaux ^^.
Mais une question reste sans réponse, il puisqu'il y a des personnes qu alifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuell e des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimis ée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare d e type
386 trainée comme un boulet ?
>> Je ne comprend pas pourquoi la traduction (voire la version
>> originale) n'emploie pas le terme de driver/pilote pour les
>> translators/traducteurs, puisqu'ils sont des serveurs servant à ça .
>> Ou alors j'ai rien compris ^^
> ?
> Là il faut faire appel à un plus grand spécialiste des
> (micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
> tout hasard...
> Sinon les traducteurs ne sont pas forcément des pilotes pour le
> matériel, ils servent à représenter quelque chose sous la forme d 'un
> système de fichier (si je ne dis pas de bêtises). Par exemple on pe ut
> avoir un traducteur représentant l'arbre des discussions de ce groupe
> sous forme d'un ensemble de fichiers/répertoire.
Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philoso phie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciau x tels les
périphériques. Finalement, tout ce monde est en mode utilisateur, et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, chang er chaque
partie du système sans droits particuliers, et sans reboot. On peut m ême
enchaîner les micro-noyaux ^^.
Mais une question reste sans réponse, il puisqu'il y a des personnes qu alifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuell e des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimis ée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare d e type
386 trainée comme un boulet ?