fil de changement de contexte vs processus de changement de contexte

Quelqu'un pourrait-il me dire ce qui est exactement fait dans les deux situations? Quel est le coût principal de chacun d'eux?

89
demandé sur Leon 2011-03-26 06:07:49

7 réponses

La principale distinction entre un commutateur de thread et un commutateur de processus est que pendant un commutateur de thread, l'espace de mémoire virtuelle reste le même, alors qu'il ne le fait pas pendant un commutateur de processus. Les deux types impliquent de transférer le contrôle au noyau du système d'exploitation pour effectuer le changement de contexte. Le processus de commutation Dans et hors du noyau du système d'exploitation ainsi que le coût de commutation des registres est le plus grand coût fixe d'effectuer un changement de contexte.

Un coût plus flou est qu'un le commutateur de contexte perturbe les mécanismes de mise en cache des processeurs. Fondamentalement, lorsque vous changez de contexte, toutes les adresses mémoire que le processeur "se souvient" dans son cache deviennent effectivement inutiles. La grande distinction ici est que lorsque vous modifiez des espaces de mémoire virtuelle, le tampon TLB (Translation Lookaside Buffer) ou équivalent du processeur est vidé, rendant les accès à la mémoire beaucoup plus chers pendant un certain temps. Cela ne se produit pas pendant un commutateur de thread.

157
répondu Abhay Buch 2013-08-12 20:46:52

La commutation de contexte de processus implique la commutation de l'espace d'adressage mémoire. Cela inclut les adresses mémoire, les mappages, les tables de pages et les ressources du noyau-une opération relativement coûteuse. Sur certaines architectures, cela signifie Même vider divers caches de processeur qui ne sont pas partageables entre les espaces d'adressage. Par exemple, x86 doit vider le TLB et certains processeurs ARM doivent vider l'intégralité du cache L1!

La commutation de Thread est une commutation de contexte d'un thread à un autre dans le même processus (passage du filet à travers le processus est juste processus de commutation).La commutation de l'état du processeur (comme le compteur de programme et le contenu du registre) est généralement très efficace.

8
répondu aditya dogra 2014-08-24 03:57:07

Tout d'abord, le système d'exploitation apporte le thread sortant en mode noyau s'il n'est pas déjà là, car le commutateur de thread ne peut être effectué qu'entre les threads, qui s'exécutent en mode noyau. Ensuite, le planificateur est appelé pour prendre une décision sur le thread auquel la commutation sera effectuée. Une fois la décision prise, le noyau enregistre une partie du contexte de thread qui se trouve dans CPU (registres cpu) dans l'endroit dédié en mémoire (souvent en haut de la pile du noyau du thread sortant). Puis le noyau effectue le passage de la pile du noyau du thread sortant à la pile du noyau du thread entrant. Après cela, le noyau charge le contexte précédemment stocké du thread entrant de la mémoire dans les registres CPU. Et, enfin, renvoie le contrôle en mode utilisateur, mais en mode utilisateur du nouveau thread. Dans le cas où le système D'exploitation a déterminé que le thread entrant s'exécute dans un autre processus, le noyau effectue une étape supplémentaire: définit un nouvel espace d'adressage virtuel actif.

Le coût principal dans les deux scénarios est lié à une pollution de cache. Dans la plupart des cas, l'ensemble de travail utilisé par le thread sortant différera considérablement de l'ensemble de travail utilisé par le thread entrant. En conséquence, le thread entrant commencera sa vie avec une avalanche de pertes de cache, vidant ainsi les données anciennes et inutiles des caches et chargeant les nouvelles données de la mémoire. La même chose est vraie pour TLB. Dans le cas de la réinitialisation de l'espace d'adressage virtuel (les threads s'exécutent dans différents processus), la pénalité est encore pire, car la réinitialisation de l'espace d'adressage virtuel conduit au vidage de TLB. La triste histoire est que TLB entier est vidé, même si le nouveau thread a réellement besoin de charger seulement quelques nouvelles entrées. En conséquence, le nouveau thread commencera son quantum de temps avec des ratés TLB et une marche de page fréquente. Le coût Direct du commutateur de threads n'est pas non plus négligeable (de ~ 250 et jusqu'à ~1500-2000 cycles) et dépend de la complexité du processeur, des états des threads et des ensembles de registres qu'ils utilisent réellement.

P.S.: bon post sur le contexte commutateur frais généraux: http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

6
répondu ZarathustrA 2016-10-27 10:16:20
  • commutation de processus: c'est une transition entre deux résidents de mémoire de processus dans un environnement multiprogrammation;
  • changement de contexte: c'est un changement de contexte d'un programme d'exécution à une routine de service d'interruption (ISR).
3
répondu john 2012-12-03 05:52:38

Dans la commutation de contexte de Thread, l'espace mémoire virtuel reste le même alors qu'il ne l'est pas dans le cas du changement de contexte de processus. En outre, le commutateur de contexte de processus est plus coûteux que le commutateur de contexte de Thread.

0
répondu Palak Jain 2018-02-14 12:40:54

En bref, le commutateur de contexte de thread n'attribue pas un nouvel ensemble de mémoire et de pid, il utilise le même que le parent puisqu'il s'exécute dans le même processus. Un processus génère un nouveau processus et attribue ainsi de nouveaux mem et pid.

Il y a un loooooot plus à elle. Ils ont écrit des livres sur elle.

En ce qui concerne le coût, un contexte de processus change > > > > thread car vous devez réinitialiser tous les compteurs de pile, etc.

-1
répondu CtrlDot 2011-03-26 03:14:30

En supposant que le processeur exécuté par le système d'exploitation a des périphériques à latence élevée attachés,

Il est logique d'exécuter un autre thread de L'Espace D'adressage du processus, tandis que le périphérique à latence élevée répond.

Mais, si le périphérique à latence élevée répond plus rapidement que le temps nécessaire pour configurer la table + traduction des mémoires virtuelles en Mémoires physiques pour un nouveau processus, il est douteux qu'un commutateur soit essentiel.

En outre, hot cache (données nécessaires pour exécuter le processus / thread est accessible en moins de temps) est un meilleur choix.

-1
répondu delete me 2015-10-17 05:02:24