C'est peut-être une question de noob totale, mais:
Je pensais que l’intérêt d’un ordinateur multicœur était de pouvoir exécuter simultanément plusieurs threads. Dans ce cas, si vous avez une machine quad-core, à quoi servirait-elle d'avoir plus de 4 threads exécutés à la fois? Ne seraient-ils pas simplement en train de voler du temps les uns aux autres?
La réponse s'articule autour de l'objet de threads, ce qui est le parallélisme: pour exécuter plusieurs des lignes distinctes de l'exécution à la fois. Dans un système "idéal", vous auriez un thread d'exécution par cœur: pas d'interruption. En réalité, ce n'est pas le cas. Même si vous disposez de quatre cœurs et quatre threads, vos processus et threads seront constamment être mis à l'écart pour les autres processus et les threads. Si vous exécutez un système d'exploitation moderne, chaque processus dispose d'au moins un fil, et beaucoup plus. Tous ces processus sont en cours d'exécution à la fois. Vous avez probablement plusieurs centaines de tous les threads en cours d'exécution sur votre machine. Vous ne jamais obtenir une situation où un thread s'exécute sans avoir le temps "volé". (Eh bien, vous pourriez si c'est de la course en temps réel, si vous utilisez un OS temps réel ou, même sous Windows, utiliser un fil en temps réel priorité. Mais il est rare.)
Avec comme toile de fond, la réponse est: Oui, plus de quatre threads sur un vrai quatre-core de la machine peut vous donner une situation où ils "voler du temps de l'autre", mais seulement si chaque thread a besoin de 100% de CPU. Si un fil ne fonctionne pas à 100% (comme un thread d'INTERFACE utilisateur pourrait ne pas être, ou d'un fil en faisant une petite quantité de travail ou de l'attente de quelque chose) puis un autre thread qui est prévu est en fait une bonne situation.
C'est en fait plus compliqué que cela:
Que faire si vous avez cinq bits de travail et qui ont besoin d'être fait à la fois? Il est plus logique de les exécuter une fois pour toutes, que pour quatre d'entre eux, puis exécutez le cinquième plus tard.
Il est rare qu'un thread pour véritablement besoin de 100% de CPU. Le moment où il utilise le disque ou sur le réseau I/O, par exemple, il peut être potentiellement passer du temps d'attente à ne rien faire d'utile. C'est une situation très courante.
Si vous avez du travail qui doit être exécuté, un mécanisme commun est d'utiliser un pool de threads. Il semble logique d'avoir le même nombre de threads que de cœurs, encore la .Net threadpool a jusqu'à 250 threads par processeur. Je ne suis pas certain pourquoi ils le font, mais je pense à voir avec la taille des tâches qui leur sont donnés pour s'exécuter sur les threads.
Donc: voler du temps n'est pas une mauvaise chose (et ce n'est pas vraiment du vol, que ce soit: c'est la façon dont le système est censé fonctionner.) Écrivez votre multithread programmes basés sur le genre de travail que le fils va faire, ce qui peut ne pas être lié au PROCESSEUR. Déterminer le nombre de fils que vous avez besoin en fonction de profilage et de la mesure. Vous pouvez trouver qu'il est plus utile de penser en termes de tâches ou de travaux, plutôt que de threads: écrire des objets de travail et de leur donner une piscine à exécuter. Enfin, à moins que votre programme est vraiment la performance est critique, ne vous inquiétez pas trop :)
Juste parce qu'un thread existe ne signifie pas toujours qu'il est activement en cours d'exécution. De nombreuses applications de threads impliquer certains d'entre les fils d'aller dormir jusqu'à ce qu'il est temps pour eux de faire quelque chose - par exemple, la saisie de l'utilisateur déclenchement de threads à se réveiller, faire un peu de traitement, et de se rendormir.
Essentiellement, les threads sont des tâches qui peuvent fonctionner indépendamment l'un de l'autre, sans avoir besoin d'être au courant de l'avancement d'une autre tâche. Il est tout à fait possible d'avoir plus de ces que vous avez la capacité d'exécuter simultanément; ils sont toujours utiles pour des raisons de commodité, même si parfois ils ont à attendre en ligne les uns derrière les autres.
Le point est que, en dépit de ne pas avoir toute véritable accélération lorsque le thread count dépasse nombre de cœurs, vous pouvez utiliser des threads pour démêler les morceaux de logique qui ne devraient pas avoir à être interdépendants.
En même modérément complexe d'application, à l'aide d'un seul fil d'essayer de tout faire rapidement fait de hachage de la "fluidité" de votre code. Le seul thread passe la plupart de son temps à cette interrogation, la vérification que, à condition que l'appel de routines en tant que de besoin, et il devient difficile de voir quelque chose, mais un fatras de détails.
Ceci contraste avec le cas où vous pouvez consacrer des threads pour les tâches de sorte que, regardant tout individu fil, vous pouvez voir ce que le thread est en train de faire. Par exemple, un thread peut bloquer en attente sur l'entrée à partir d'une prise, d'analyser les flux dans les messages, filtrer les messages, et quand un message valide qui vient, à passer à un autre thread. Le thread peut travailler sur les entrées à partir d'un certain nombre d'autres sources. Le code pour chacun de ces exposera propre, déterminée et de débit, sans avoir à rendre explicite vérifie qu'il n'y a pas autre chose à faire.
Divisant le travail de cette façon permet à votre application de compter sur le système d'exploitation de prévoir quoi faire avec le cpu, de sorte que vous n'avez pas à rendre explicite le conditionnel vérifie partout dans votre application sur ce qui pourrait bloquer et ce qui est prêt à traiter.
Bien que vous pouvez certainement utiliser des threads pour accélérer les calculs en fonction de votre matériel, l'une de leurs principales utilisations est de faire plus d'une chose à un moment de convivialité raisons.
Par exemple, si vous avez à faire un peu de traitement en arrière-plan et restent également sensible à l'INTERFACE de saisie, vous pouvez utiliser les threads. Sans fils, l'interface utilisateur peut se bloquer à chaque fois que vous avez essayé de faire tout le traitement lourd.
Voir aussi cette question: http://stackoverflow.com/questions/574072/practical-uses-for-threads
Je suis en total désaccord avec @kyoryu l'affirmation que le nombre idéal est un thread par CPU.
Pensez-y de cette façon: pourquoi avons-nous du multi-processing systèmes d'exploitation? Pour la plupart de l'histoire de l'informatique, près de tous les ordinateurs avaient une CPU. Pourtant, depuis les années 1960, tous les "vrais" ordinateurs avaient multi-processing (aka multi-tâches) des systèmes d'exploitation.
Vous exécutez plusieurs programmes de manière à ce que l'on peut exécuter tandis que d'autres sont bloqués pour des choses comme les IO.
permet de mettre de côté les arguments quant à savoir si les versions de Windows NT avant ont été multi-tâches. Depuis, tous les OS avaient multi-tâches. Certains ne l'exposez pas à des utilisateurs, mais il est là de toute façon, en faisant des choses comme l'écoute du téléphone portable de radio, parlent de la puce GPS, l'acceptation de la souris, etc.
Les Threads sont juste des tâches qui sont un peu plus efficaces. Il n'y a pas de différence fondamentale entre une tâche, un processus et thread.
Un PROCESSEUR est une chose terrible à gaspiller, donc beaucoup de choses prêt à l'utiliser quand vous le pouvez.
Je suis d'accord qu'avec la plupart des langages procéduraux, C, C++, Java, etc, écrit bon thread-safe code est beaucoup de travail. Avec 6-core, les Processeurs sur le marché aujourd'hui, et 16 Processeurs core non loin de là, je pense que les gens vont se déplacer loin de ces langues anciennes, comme le multi-threading est de plus en plus une exigence essentielle.
Désaccord avec @kyoryu est juste mon humble avis, le reste est fait.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
