Un thread est "léger" car la plus grande partie de l'overhead a déjà été accomplie grâce à la création de son processus. J'ai trouvé cela dans l'un des tutoriels.Pourquoi les threads sont-ils appelés processus légers?
Quelqu'un peut-il préciser ce que cela signifie exactement?
L'affirmation selon laquelle les fils sont «légers» est - selon la plate-forme - pas nécessairement fiable.
Un thread de système d'exploitation doit prendre en charge l'exécution de code natif, par ex. écrit en C. Donc, il doit fournir une pile de taille décente, généralement mesurée en mégaoctets. Donc, si vous avez démarré 1000 threads (peut-être dans le but de prendre en charge 1000 connexions simultanées à votre serveur), vous aurez besoin d'une mémoire de 1 Go avant même de commencer à travailler.
Ceci est un réel problème dans les serveurs hautement évolutifs, ils n'utilisent donc pas de threads comme s'ils étaient légers. Ils les traitent comme des ressources lourdes. Ils peuvent à la place créer un nombre limité de threads dans un pool et les laisser prendre des éléments de travail dans une file d'attente. Comme cela signifie que les threads ont une longue durée de vie et sont peu nombreux, il peut être préférable d'utiliser des processus à la place. De cette façon, vous obtenez l'isolation de l'espace d'adressage et il n'y a pas vraiment de problème avec le manque de ressources. En résumé: méfiez-vous des revendications «marketing» faites au nom des threads. Le traitement parallèle est génial (de plus en plus essentiel), mais les threads ne sont qu'un moyen d'y parvenir.
+1 Spot on - n'aurait pas pu le mettre mieux moi-même – zebrabox
J'aime le résumé. J'ai tendance à préférer utiliser plusieurs processus monothread, et je le déteste quand des fan-threads multi-threads m'accusent de ne pas tirer profit du parallélisme multi-core facile car ils n'entendent pas l'idée de processus multiples. –
Merci. Il existe de nombreuses raisons pour lesquelles le processus peut parfois être meilleur que les threads. Un qui m'a surpris était que vous pourriez obtenir un coup de pouce de performance gratuit! La raison en est que les processus séparés ont des tas de mémoire C séparés. Dans une bibliothèque standard thread-safe, tous les appels 'malloc' /' free' doivent être synchronisés, ce qui pourrait signifier une tonne de verrouillage en fonction de votre utilisation de la mémoire. J'ai vu une application utilisant des threads décrocher à 4 cœurs, mais lorsqu'elle est passée à des processus séparés, elle passait à 8 (et probablement plus, n'avait pas plus de cœurs à tester). Moins vous partagez de mémoire, moins vous devez synchroniser. –
La création de processus est "coûteuse", car elle doit configurer un nouvel espace mémoire virtuel complet pour le processus avec son propre espace d'adressage. "cher" signifie que cela prend beaucoup de temps CPU.
Les threads n'ont pas besoin de faire cela, il suffit de changer quelques pointeurs, donc c'est beaucoup moins cher que de créer un processus. La raison pour laquelle les threads n'ont pas besoin de cela est parce qu'ils s'exécutent dans l'espace d'adressage, et dans la mémoire virtuelle du processus parent.
Chaque processus doit avoir au moins un thread. Donc, si vous y réfléchissez, créer un processus signifie créer le processus ET créer un fil de discussion. Évidemment, créer seulement un thread prendra moins de temps et de travail par l'ordinateur. En outre, les threads sont "légers" car les threads peuvent interagir sans nécessiter de communication inter-processus. Passer d'un thread à l'autre est moins coûteux que de passer d'un processus à un autre (encore une fois, déplacer quelques pointeurs). Et la communication inter-processus nécessite une communication plus coûteuse que les threads.
Les threads au sein d'un processus partagent le même espace de mémoire virtuelle, mais chacun a une pile distincte, et éventuellement un "stockage local de threads" s'il est implémenté. Ils sont léger parce qu'un changement de contexte est simplement un cas de commutation du pointeur de pile et du compteur de programme et de la restauration d'autres registres, où un changement de contexte processus implique également de basculer le contexte MMU.
En outre, la communication entre les threads dans un processus est léger car ils partagent un espace d'adressage.
Ce n'est pas léger si vous avez un système mulit-core qui a besoin de synchroniser les données entre les caches L1 pour les threads mulliple - en fait c'est tout sauf léger – zebrabox
@zebrabox: Aucun doute vrai. Comme toujours, ces termes deviennent sans importance avec le temps. La plupart de mes travaux portent sur des systèmes embarqués à noyau unique avec des noyaux RTOS, de sorte que de telles complexités ont rarement eu lieu - tout est un fil - même lorsqu'elles sont protégées par une MMU (contrairement à ce que je disais plus tôt!). – Clifford
Oui, je sais d'où vous venez. Il est évidemment beaucoup moins d'un problème sur une seule machine de base - surtout si vous avez accès à un couple de threads matériels :) – zebrabox
:
fil:
Procédé contient un ou plusieurs fils en elle et un fil peuvent faire tout ce processus peut faire. Les threads au sein d'un processus partagent le même espace d'adressage car le coût de communication entre threads est faible car il utilise la même section de code, la même section de données et les ressources du système d'exploitation.
En conservant la création de processus et votre système d'exploitation, vous verrez combien il y a de frais généraux pour créer un processus. –
@Non Remboursements Aucun retour: Et vous trouverez qu'il diffère considérablement entre les systèmes d'exploitation. –
@Non Remboursements Aucun retour: quelle est la surdécouverte de la synchronisation du cache entre les threads sur une machine multicœur ou la surcharge du changement de contexte et l'enregistrement de l'état de la pile et du jeu de registres? – zebrabox