> De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
"Te soumet potentiellement à un changement de contexte" est vrai.
Mais dans quel cas ?
Il y a changement de contexte s'il n'y a pas assez de cpu (le cpu est alors affecté à un autre thread qui en a besoin). On est dans le cas où il n'y a moins de cpu que de threads actifs/éligibles et au-lieu de laisser un cpu en attende d'un lock, on l'affecte à un autre thread.
Il y a aussi changement de contexte si le thread reste longtemps (c'est très court :-)) en attente du lock. Dans ce cas le thread passe en sommeil et sera réveillé plus tard. On est dans le cas où il n'y a rien à faire pour ce thread/cpu. On ne manque pas de cpu (en nombre, pas forcément en puissance puisqu'on peut attendre le traitement d'un autre cpu). Dans ce cas passer le thread en mode sommeil (et probablement le cpu qui l'exécutait) permet d'économiser de l'énergie. Ceci sans que les performances en souffre ou alors que très faiblement. Le thread qui était en attente (et n'avait rien à faire) sera réveillé un peu moins vite.
Il faut noter qu'on peut faire typiquement des milliers de lock à la second dans une appli multi-threadé. En général il n'y a qu'un faible pourcentage de ces locks qui demande un changement de contexte (si on a un nombre de cpu adapté à l'appli).
Plus techniquement (mais en très simplifié) un mutex fait en premier :
while (!ma_condition && ++compteur < boucle_attente) ;
Si le thread/cpu sort de la boucle et que ma_condition est vrai, il continue, sinon il passe en sommeil et l'OS le réveillera lorsque ma_condition devient vrai.
[^] # Re: Multicoeur ?
Posté par IsNotGood . En réponse à la dépêche Intel libère TBB. Évalué à 0.
"Te soumet potentiellement à un changement de contexte" est vrai.
Mais dans quel cas ?
Il y a changement de contexte s'il n'y a pas assez de cpu (le cpu est alors affecté à un autre thread qui en a besoin). On est dans le cas où il n'y a moins de cpu que de threads actifs/éligibles et au-lieu de laisser un cpu en attende d'un lock, on l'affecte à un autre thread.
Il y a aussi changement de contexte si le thread reste longtemps (c'est très court :-)) en attente du lock. Dans ce cas le thread passe en sommeil et sera réveillé plus tard. On est dans le cas où il n'y a rien à faire pour ce thread/cpu. On ne manque pas de cpu (en nombre, pas forcément en puissance puisqu'on peut attendre le traitement d'un autre cpu). Dans ce cas passer le thread en mode sommeil (et probablement le cpu qui l'exécutait) permet d'économiser de l'énergie. Ceci sans que les performances en souffre ou alors que très faiblement. Le thread qui était en attente (et n'avait rien à faire) sera réveillé un peu moins vite.
Il faut noter qu'on peut faire typiquement des milliers de lock à la second dans une appli multi-threadé. En général il n'y a qu'un faible pourcentage de ces locks qui demande un changement de contexte (si on a un nombre de cpu adapté à l'appli).
Plus techniquement (mais en très simplifié) un mutex fait en premier :
while (!ma_condition && ++compteur < boucle_attente) ;
Si le thread/cpu sort de la boucle et que ma_condition est vrai, il continue, sinon il passe en sommeil et l'OS le réveillera lorsque ma_condition devient vrai.