> J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre
Ce n'est pas très claire. Un processus n'est pas un thread, c'est un environnement (mémoire, variable d'environnement, etc). Un processus a par défaut un thread (celui qui excécute main()). Un processus n'est pas attaché à un cpu pour la bonne raison qu'un processus peut avoir plusieurs threads.
Par exemple :
processus : toto avec 2 thread.
thread 1 de toto : s'exécute sur le premier cpu
thread 2 de toto : s'exécute sur le second cpu
A quel cpu est attaché le processus ? Aucun.
Sous linux aussi a chaque processus il y a au minimum un thread.
Exemple :
[admin@one rsync]$ ls -d /proc/5551
/proc/5551 // processus 5551
[admin@one rsync]$ ls /proc/5551/task/
5551 // thread 5551
C'est un processus (non multi-thread) qui n'a qu'un thread (il doit obligatoirement en avoir au moins un).
La différence avec Windows est que les numéros de processus et de thread son partagé. Sous Linux le numéro du premier thread d'un processus est égale au numéro du processus.
> l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...).
Tout est normal, l'OS est là pour utiliser au mieux les ressources. Si deux thread sont attachés à un même cpu et qu'un cpu ne fout rien, l'OS va attacher un thread à un autre cpu.
En fait, on ne peut avoir deux threads sur un même cpu. Un thread est réveillé que s'il y a un cpu de disponible. Tout se faire, l'OS peut décider de mettre en sommeil un autre thread (afin de libérer un cpu).
Notons qu'un thread en sommeil n'est pas attaché à un cpu. Donc lorsque l'OS le réveille il peut l'attacher à n'importe quel cpu. Ça ne fait pas plus de boulot pour l'OS. Mais il vaut mieux le rattacher au cpu où il s'exécutait avant car le cache du cpu a peut-être des données que le thread va utiliser.
> mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
Pas vraiment. Tant que le thread est actif, il ne change pas de cpu. Mais dès qu'il est en sommeil il peut changer de cpu. Qu'il possède un lock ou soit en attende d'un lock n'y change rien.
Le thread peut passer en sommeil pour différentes raisons :
- l'ordonnanceur estime qu'il a écoulé son quantum de cpu et donc le passe en sommeil pour donner du cpu à un autre thread.
- le thread est passé en sommeil car il attend un lock, un semaphore, la lecture d'un fichier, etc... L'OS peut le changer de cpu au prochain réveil.
Changer de cpu un thread coûte peu. Il peut y avoir des problèmes d'utilisation du cache du cpu.
Exemple : j'ai trois threads mais 2 seulements s'exécute en même temps. Lorsqu'un thread tourne, il le fait pour très très peu de temps.
Imaginons que j'ai thread_A thread_B thread_C et deux cpu : cpu_1 cpu_2.
On peut avoir ce cas :
cpu_1 : thread_A
cpu_2 : thread_B
// thread_A passe en sommeil et thread_C est réveillé
cpu_1 : thread_C
cpu_2 : thread_B
// thread_B passe en sommeil et thread_A est réveillé
cpu_1 : thread_C // le cache de cpu_1a peut-être des données de thread_A
cpu_2 : thread_A
etc...
Les threads n'arrêtent pas de passer de cpu_1 à cpu_2 et vice versa. Le cache des cpu est mal utilisé.
[^] # Re: Multicoeur ?
Posté par IsNotGood . En réponse à la dépêche Intel libère TBB. Évalué à 0.
Ce n'est pas très claire. Un processus n'est pas un thread, c'est un environnement (mémoire, variable d'environnement, etc). Un processus a par défaut un thread (celui qui excécute main()). Un processus n'est pas attaché à un cpu pour la bonne raison qu'un processus peut avoir plusieurs threads.
Par exemple :
processus : toto avec 2 thread.
thread 1 de toto : s'exécute sur le premier cpu
thread 2 de toto : s'exécute sur le second cpu
A quel cpu est attaché le processus ? Aucun.
Sous linux aussi a chaque processus il y a au minimum un thread.
Exemple :
[admin@one rsync]$ ls -d /proc/5551
/proc/5551 // processus 5551
[admin@one rsync]$ ls /proc/5551/task/
5551 // thread 5551
C'est un processus (non multi-thread) qui n'a qu'un thread (il doit obligatoirement en avoir au moins un).
La différence avec Windows est que les numéros de processus et de thread son partagé. Sous Linux le numéro du premier thread d'un processus est égale au numéro du processus.
> l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...).
Tout est normal, l'OS est là pour utiliser au mieux les ressources. Si deux thread sont attachés à un même cpu et qu'un cpu ne fout rien, l'OS va attacher un thread à un autre cpu.
En fait, on ne peut avoir deux threads sur un même cpu. Un thread est réveillé que s'il y a un cpu de disponible. Tout se faire, l'OS peut décider de mettre en sommeil un autre thread (afin de libérer un cpu).
Notons qu'un thread en sommeil n'est pas attaché à un cpu. Donc lorsque l'OS le réveille il peut l'attacher à n'importe quel cpu. Ça ne fait pas plus de boulot pour l'OS. Mais il vaut mieux le rattacher au cpu où il s'exécutait avant car le cache du cpu a peut-être des données que le thread va utiliser.
> mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
Pas vraiment. Tant que le thread est actif, il ne change pas de cpu. Mais dès qu'il est en sommeil il peut changer de cpu. Qu'il possède un lock ou soit en attende d'un lock n'y change rien.
Le thread peut passer en sommeil pour différentes raisons :
- l'ordonnanceur estime qu'il a écoulé son quantum de cpu et donc le passe en sommeil pour donner du cpu à un autre thread.
- le thread est passé en sommeil car il attend un lock, un semaphore, la lecture d'un fichier, etc... L'OS peut le changer de cpu au prochain réveil.
Changer de cpu un thread coûte peu. Il peut y avoir des problèmes d'utilisation du cache du cpu.
Exemple : j'ai trois threads mais 2 seulements s'exécute en même temps. Lorsqu'un thread tourne, il le fait pour très très peu de temps.
Imaginons que j'ai thread_A thread_B thread_C et deux cpu : cpu_1 cpu_2.
On peut avoir ce cas :
cpu_1 : thread_A
cpu_2 : thread_B
// thread_A passe en sommeil et thread_C est réveillé
cpu_1 : thread_C
cpu_2 : thread_B
// thread_B passe en sommeil et thread_A est réveillé
cpu_1 : thread_C // le cache de cpu_1a peut-être des données de thread_A
cpu_2 : thread_A
etc...
Les threads n'arrêtent pas de passer de cpu_1 à cpu_2 et vice versa. Le cache des cpu est mal utilisé.