Quelle est la différence entre la fourchette et le fil?
Quelqu'un peut-il expliquer la différence entre une fourchette et un fil?
Une fourchette vous donne un tout nouveau processus, qui est une copie du processus actuel, avec les mêmes segments de code. Au fur et à mesure que l'image mémoire change (cela est généralement dû à un comportement différent des deux processus), vous obtenez une séparation des images mémoire (copie à l'écriture), mais le code exécutable reste le même. Les tâches ne partagent pas la mémoire sauf si elles utilisent une primitive Inter Process Communication (IPC) .
Un processus peut avoir plusieurs threads, chacun s'exécutant en parallèle dans le même contexte du processus. La mémoire et les autres ressources sont partagées entre les threads, donc les données partagées doivent être accessibles via certains objets primitifs et de synchronisation (comme mutexes , variables de condition et sémaphores ) qui vous permettent d'éviter la corruption des données.
Fourchette:
Fork n'est rien d'autre qu'un nouveau processus qui ressemble exactement à l'ancien ou au processus parent, mais il s'agit tout de même d'un processus différent avec un ID de processus différent et ayant sa propre mémoire. Le processus parent crée un espace d'adressage séparé pour l'enfant. Les processus parent et enfant possèdent le même segment de code, mais s'exécutent indépendamment l'un de l'autre.
L'exemple le plus simple de bifurquer est lorsque vous exécutez une commande sur Shell sous unix/linux. Chaque fois qu'un utilisateur émet une commande, le shell lance un processus enfant et la tâche est terminée.
Lorsqu'un appel système fork est émis, une copie de toutes les pages correspondant au processus parent est créée, chargée dans un emplacement mémoire séparé par le système d'exploitation pour le processus enfant, mais dans certains cas, cela n'est pas nécessaire. Comme dans les appels système ‘exec’, il n’est pas nécessaire de copier les pages du processus parent, car execv remplace l’espace d’adresse du processus parent lui-même.
Peu de choses à noter sur la fourche sont:
- Le processus enfant aura son propre ID de processus unique.
- Le processus enfant doit avoir sa propre copie du descripteur de fichier du parent.
- Les verrous de fichier définis par le processus parent ne doivent pas être hérités par le processus enfant.
- Tous les sémaphores ouverts dans le processus parent doivent également l'être dans le processus enfant.
- Le processus enfant doit avoir sa propre copie des descripteurs de file d'attente de messages des parents.
- L'enfant aura son propre espace d'adressage et sa propre mémoire.
Fils:
Les threads sont des processus légers (LWP). Traditionnellement, un thread n'est qu'un état CPU (et un autre état minimal) avec le processus contenant les restes (données, pile, E/S, signaux). Les threads nécessitent moins de temps système que le "forking" ou le lancement d'un nouveau processus car le système n'initialise pas un nouvel espace de mémoire virtuelle et un nouvel environnement système pour le processus. Bien que plus efficace sur un système multiprocesseur où le flux de processus peut être planifié pour s'exécuter sur un autre processeur, gagnant ainsi de la vitesse grâce à un traitement parallèle ou distribué, des gains se trouvent également sur les systèmes à processeur unique qui exploitent la latence des E/S et d'autres fonctions du système qui peuvent interrompre le processus. exécution.
Les threads du même partage de processus:
- Instructions de processus
- La plupart des données
- fichiers ouverts (descripteurs)
- signaux et gestionnaires de signaux
- répertoire de travail actuel
- Identifiant de l'utilisateur et du groupe
Plus de détails peuvent être trouvés ici .
La réponse de Dacav est excellente, je voulais juste ajouter que tous les modèles de threads ne vous offrent pas un véritable multi-traitement.
Par exemple, l'implémentation de thread par défaut de Ruby n'utilise pas de vrais threads OS/noyau. Au lieu de cela, il imite la présence de plusieurs threads en basculant entre les objets Thread dans un seul thread/processus du noyau.
Ceci est important sur les systèmes multiprocesseurs/multi-cœurs, car ces types de threads légers ne peuvent s'exécuter que sur un seul cœur - vous n'obtenez pas beaucoup d'amélioration des performances en ayant plusieurs threads.
L'autre endroit où cela fait une différence est lorsqu'un bloc de threads (en attente d'E/S ou appelant l'IOCTL d'un pilote), tous les blocs de threads.
Ce n'est pas très courant de nos jours - la plupart des implémentations de threads utilisent des threads du noyau qui ne souffrent pas de ces problèmes - mais cela vaut la peine d'être mentionné pour être complet.
En revanche, fork vous donne un autre processus qui peut être exécuté simultanément sur un autre CPU physique pendant que le processus d'origine est en cours d'exécution. Certaines personnes trouvent que IPC convient mieux à leur application, d'autres préfèrent le filetage.
Bonne chance et amusez-vous bien! Le multi-threading est à la fois stimulant et gratifiant.
- Les threads partagent l'espace d'adressage du processus qui l'a créé; les processus ont leur propre espace d'adressage.
- Les threads ont un accès direct au segment de données de son processus; les processus ont leur propre copie du segment de données du processus parent.
- Les threads peuvent communiquer directement avec d'autres threads de son processus; les processus doivent utiliser la communication interprocessus pour communiquer avec les processus frères.
- Les threads n'ont presque pas de frais généraux; les processus ont des frais généraux considérables.
- De nouveaux fils sont facilement créés; les nouveaux processus nécessitent la duplication du processus parent.
- Les threads peuvent exercer un contrôle considérable sur les threads du même processus; les processus ne peuvent exercer un contrôle que sur les processus enfants.
- Les modifications apportées au thread principal (annulation, changement de priorité, etc.) peuvent affecter le comportement des autres threads du processus; les modifications apportées au processus parent n'affectent pas les processus enfants
Les threads sont des fonctions exécutées en parallèle, fork est un nouveau processus avec l'héritage des parents. Les threads sont bons pour exécuter une tâche en parallèle, tandis que les fourches sont des processus indépendants, qui s'exécutent également simultanément. Les threads ont des conditions de concurrence et contrôlent les sémaphores et les verrous ou mutex, les tuyaux peuvent tous deux être utilisés dans la fourche et le fil.