Autrefois, la mémoire n'était pas virtualisée ou protégée et n'importe quel code pouvait écrire n'importe où. À l'époque, une conception de type "un thread pour un CPU" avait du sens. Au cours des décennies qui ont suivi, la mémoire a d'abord été protégée, puis virtualisée. Considérez les threads comme des cœurs virtuels - une sorte de promesse qu'à un moment donné, lorsque vos données et votre code seront prêts, ce thread sera poussé ( ou programmé, comme l'appellent les ingénieurs et les mathématiciens qui font des recherches sur les algorithmes de programmation. ) sur un processeur réel pour effectuer un travail réel.

• https://people.eecs.berkeley.edu/%7Ercs/research/interactive_latency.html

En raison de l'ampleur de la différence de temps, le processeur et la mémoire cache fonctionnent si rapidement par rapport à l'obtention de données à partir du stockage ou du réseau, que des milliers de threads peuvent aller et venir pendant qu'un thread attend que www.google.com lui livre un ou deux paquets de données.

Si vous convertissez les opérations de fil qui se produisent sur l'échelle de temps noir/bleu et les convertissez en une seconde = 1 ns, les choses dont nous nous soucions sont plus comme les IO de disque prennent 100 microsecondes sont comme 4 jours et un aller-retour internet de 200 ms est un retard de 20 ans si vous comptez les secondes sur l'échelle de temps du CPU. Comme plusieurs exercices de puissances de dix Dans la plupart des cas, l'unité centrale reste inactive pendant des mois en attendant un travail significatif de la part d'un monde extérieur très, très lent.

Rien ne semble anormal dans l'image que vous avez postée. Nous ne comprenons peut-être pas où vous voulez en venir en vous interrogeant sur les fils.

Si vous cliquez avec le bouton droit de la souris sur le mot "threads" dans la ligne d'en-tête en haut, ajoutez le statut de l'application et vous verrez que la plupart des threads sont probablement inactifs, en sommeil, non exécutés à un moment donné.

Vous ne posez pas la question, sans doute plus fondamentale, "Comment puis-je avoir 290 processus alors que mon processeur n'a que quatre cœurs ?". Cette réponse est un peu d'histoire, qui pourrait vous aider à comprendre la vue d'ensemble, même si la question spécifique a déjà été répondue. En tant que tel, je ne vais pas donner une version TL;DR.

Il fut un temps (pensez aux années 50 et 60) où les ordinateurs ne pouvaient faire qu'une seule chose à la fois. Ils étaient très chers, remplissaient des pièces entières, et il fallait trouver un moyen de les utiliser efficacement en les partageant entre plusieurs personnes. La première façon de le faire était traitement par lot Les utilisateurs soumettent des tâches à l'ordinateur, qui les met en file d'attente, les exécute les unes après les autres et renvoie les résultats à l'utilisateur. C'était bien, mais cela signifiait que, si vous vouliez faire un calcul qui allait prendre quelques jours, personne d'autre ne pouvait utiliser l'ordinateur pendant ce temps.

L'innovation suivante (pensez aux années 60-70) était Partage du temps de travail . Maintenant, au lieu d'exécuter la totalité d'une tâche, puis la totalité de la tâche suivante, l'ordinateur exécuterait une partie d'une tâche, puis ferait une pause et exécuterait une partie de la tâche suivante, et ainsi de suite. Ainsi, l'ordinateur donne l'impression qu'il exécute plusieurs processus simultanément. Le grand avantage de ce système est que vous pouvez maintenant effectuer un calcul qui prendra quelques jours et, bien qu'il prenne encore plus de temps, parce qu'il est constamment interrompu, d'autres personnes peuvent toujours utiliser la machine pendant ce temps.

Tout cela pour d'énormes ordinateurs de type mainframe. Lorsque les ordinateurs personnels ont commencé à devenir populaires, ils n'étaient pas très puissants au départ et, comme ils étaient personnel il semblait normal qu'ils ne puissent faire qu'une seule chose&nbdp;- exécuter une application - à la fois (pensez aux années 1980). Mais, au fur et à mesure qu'ils devenaient plus puissants (des années 1990 à aujourd'hui), les gens ont voulu que leurs ordinateurs personnels puissent aussi partager leur temps.

Nous nous sommes donc retrouvés avec des ordinateurs personnels qui donnaient l'illusion d'exécuter plusieurs processus simultanément en les exécutant un par un pendant de brèves périodes, puis en les mettant en pause. Les threads sont essentiellement la même chose : finalement, les gens ont voulu que même les processus individuels donnent l'illusion de faire plusieurs choses en même temps. Au début, l'auteur de l'application devait s'en charger lui-même : il devait passer un peu de temps à mettre à jour les graphiques, mettre cela en pause, passer un peu de temps à calculer, mettre cela en pause, passer un peu de temps à faire autre chose, ...

Cependant, le système d'exploitation étant déjà bon pour gérer des processus multiples, il était logique de l'étendre pour gérer ces sous-processus, qui sont appelés threads. Ainsi, nous avons maintenant un modèle où chaque processus (ou application) contient au moins un thread, mais certains en contiennent plusieurs ou beaucoup. Chacun de ces threads correspond à une sous-tâche quelque peu indépendante.

Mais, au niveau supérieur, le CPU ne fait que donner l'illusion que ces threads fonctionnent tous en même temps. En réalité, il en exécute un pendant un petit moment, le met en pause, en choisit un autre à exécuter pendant un petit moment, et ainsi de suite. Sauf que les CPU modernes peuvent faire tourner plus d'un thread à la fois. Ainsi, dans le réel En réalité, le système d'exploitation joue le jeu de "exécuter un peu, faire une pause, exécuter autre chose un peu, faire une pause" sur tous les cœurs simultanément. Vous pouvez donc avoir autant de threads que vous (et les concepteurs de votre application) le souhaitez mais, à tout moment, tous les threads sauf quelques-uns seront en pause.