Quelle est la durée entre les changements de contexte sous Windows?

Question

lecture CLR via C# 2.0 (je n'ai pas 3.0 avec moi pour le moment)

Est-ce encore le cas:

S'il n'y a qu'un seul processeur dans un ordinateur, un seul thread peut fonctionner à tout temps. Windows doit garder une trace des objets thread, et de temps en temps, Windows doit décider quel thread à programmer pour aller à la CPU. C'est un code supplémentaire qui doit s'exécuter une fois toutes les 20 millisecondes environ. Lorsque Windows arrête l'exécution du code d'un thread par un processeur et commence à exécuter le code d'un autre thread, nous l'appelons un commutateur de contexte. Un changement de contexte est assez cher car le système d'exploitation doit:

Donc, circa CLR via C# 2.0 laisse dire que nous sommes sur Pentium 4 2.4ghz 1 core non-HT, XP. Toutes les 20 millisecondes? Lorsqu'un thread CLR ou un thread Java est mappé à un thread OS seulement un maximum de 50 threads par seconde peut avoir une chance de s'exécuter?

J'ai lu que le changement de contexte est très rapide en mircoseconds ici sur le SO, mais combien de fois à peu près (hypothèses de style de magnitude) va dire un ancien serveur Windows 5 ans 2003 modeste Pentium Xeon simple core donne le système d'exploitation la possibilité au changement de contexte? 20ms dans la bonne zone?

Je n'ai pas besoin de chiffres exacts Je veux juste être sûr que c'est dans la bonne zone, me semble plutôt longue.

Answer 1

Votre calcul "50 threads à la fois" est incorrect. Vous supposez que chacun de ces threads est dans un état 100% CPU. La plupart des threads sont en fait en attente d'IO ou d'autres événements. Même dans ce cas, la plupart des threads n'utilisent pas la totalité de leurs 20 ms avant de passer en mode IO ou d'abandonner leur tranche.

Essayez ceci. Ecrire une application avec une boucle inifinite (mange toute sa fenêtre CPU). Exécutez 50 instances de celui-ci. Voyez comment Windows réagit.

Answer 2

Je viens de faire un test, j'ai 43 threads voir sa part dans une seconde (après échauffement) qui rend la déclaration Richter assez précis (avec frais généraux) je dis. Quadcore/Win7/64bit. Oui, ils étaient 100% cpu threads donc évidemment ils ne se sont pas donnés avant leur 20ms. Intéressant

Answer 3

Le Quantum, comme son nom l'indique, dépend de quelques facteurs, notamment des ajustements de performances apportés par le système d'exploitation au fur et à mesure; par exemple, le processus de premier plan reçoit une priorité plus élevée et peut être donné [un quantum 3 fois plus long que le défaut. Il y a aussi une différence entre SKU serveur et client, typiquement un client aurait un quantum par défaut de 30ms où un serveur serait de 180ms.

Donc un processus de premier plan qui veut autant de CPU qu'il peut obtenir peut obtenir un quantum de 90ms avant un changement de contexte .. et ensuite le système d'exploitation peut décider qu'il n'a pas besoin de changer et laisser le Quantum continuer.