Qu'est-ce qu'un «fil» (vraiment)?

J'ai essayé de trouver une bonne définition et de comprendre ce qu'est vraiment un fil .

Il semble que je dois manquer quelque chose d'évident, mais chaque fois que je lis ce qu'est un thread, c'est presque une définition circulaire, à la "un thread est un thread d'exécution" ou "un moyen de se diviser en tâches en cours d'exécution". Euh euh. Hein?

Il semble d'après ce que j'ai lu qu'un fil n'est pas vraiment quelque chose de concret, comme un processus. Ce n'est en fait qu'un concept. D'après ce que je comprends de la façon dont cela fonctionne, un processeur exécute certaines commandes pour un programme (qui a été appelé un fil d'exécution ), puis lorsqu'il doit passer au traitement pour un autre programme pendant un peu, il stocke l' état de le programme qu'il exécute actuellement quelque part (Thread Local Storage), puis commence à exécuter les instructions de l'autre programme. Et d'avant en arrière. Telle que, un thread n'est vraiment qu'un concept pour "l'un des chemins d'exécution" d'un programme en cours d'exécution.

Contrairement à un processus, qui est vraiment quelque chose - c'est un conglomérat de ressources, etc.

Comme exemple d'une définition qui ne m'a pas vraiment aidé beaucoup. . .

De Wikipédia :

"Un thread en informatique est l'abréviation d'un thread d'exécution. Les threads sont un moyen pour un programme de se diviser (appelé" split ") lui-même en deux ou plusieurs tâches en cours d'exécution simultanées (ou pseudo-simultanées). Les threads et les processus diffèrent d'un du système d'exploitation à un autre mais, en général, un thread est contenu dans un processus et différents threads du même processus partagent les mêmes ressources, contrairement aux différents processus du même système d'exploitation multitâche. "

Ai-je raison? Faux? Qu'est-ce qu'un fil vraiment?

Edit: Apparemment, un thread a également sa propre pile d'appels, c'est donc quelque chose de concret .

Un thread est un ensemble indépendant de valeurs pour les registres du processeur (pour un seul cœur). Étant donné que cela inclut le pointeur d'instructions (également appelé compteur de programmes), il contrôle ce qui s'exécute dans quel ordre. Il comprend également le Stack Pointer, qui ferait mieux de pointer vers une zone de mémoire unique pour chaque thread, sinon ils interféreront les uns avec les autres.

Les threads sont l'unité logicielle affectée par le flux de contrôle (appel de fonction, boucle, goto), car ces instructions fonctionnent sur le pointeur d'instructions, et qui appartient à un thread particulier. Les threads sont souvent planifiés selon un schéma de priorisation (bien qu'il soit possible de concevoir un système avec un thread par cœur de processeur, auquel cas chaque thread est toujours en cours d'exécution et aucune planification n'est nécessaire).

En fait, la valeur du pointeur d'instruction et de l'instruction stockée à cet emplacement est suffisante pour déterminer une nouvelle valeur pour le pointeur d'instruction. Pour la plupart des instructions, cela fait simplement avancer l'IP de la taille de l'instruction, mais les instructions de flux de contrôle modifient l'IP d'autres manières prévisibles. La séquence de valeurs que l'IP prend forme un chemin d'exécution se tissant à travers le code du programme, donnant naissance au nom "thread".

Un thread est un contexte d'exécution, c'est-à-dire toutes les informations dont un processeur a besoin pour exécuter un flux d'instructions.

Supposons que vous lisez un livre et que vous vouliez faire une pause tout de suite, mais que vous souhaitiez pouvoir revenir et reprendre la lecture au point exact où vous vous êtes arrêté. Une façon d'y parvenir consiste à noter le numéro de page, le numéro de ligne et le numéro de mot. Votre contexte d'exécution pour lire un livre est donc ces 3 chiffres.

Si vous avez une colocataire et qu'elle utilise la même technique, elle peut prendre le livre pendant que vous ne l'utilisez pas et reprendre la lecture à l'endroit où elle s'est arrêtée. Ensuite, vous pouvez le reprendre et le reprendre d'où vous étiez.

Les threads fonctionnent de la même manière. Un processeur vous donne l'illusion qu'il effectue plusieurs calculs en même temps. Il le fait en passant un peu de temps sur chaque calcul. Il peut le faire car il a un contexte d'exécution pour chaque calcul. Tout comme vous pouvez partager un livre avec votre ami, de nombreuses tâches peuvent partager un processeur.

Sur un plan plus technique, un contexte d'exécution (donc un thread) est constitué des valeurs des registres du CPU.

Dernier: les threads sont différents des processus. Un thread est un contexte d'exécution, tandis qu'un processus est un ensemble de ressources associées à un calcul. Un processus peut avoir un ou plusieurs threads.

Clarification: les ressources associées à un processus comprennent des pages de mémoire (tous les threads d'un processus ont la même vue de la mémoire), des descripteurs de fichier (par exemple, des sockets ouverts) et des informations d'identification de sécurité (par exemple, l'ID de l'utilisateur qui a démarré le processus).

Afin de définir un thread de manière formelle, nous devons d'abord comprendre les limites de l'endroit où un thread opère.

Un programme informatique devient un processus lorsqu'il est chargé à partir d'un magasin dans la mémoire de l'ordinateur et commence son exécution. Un processus peut être exécuté par un processeur ou un ensemble de processeurs. Une description de processus en mémoire contient des informations vitales telles que le compteur de programme qui garde une trace de la position actuelle dans le programme (c'est-à-dire quelle instruction est en cours d'exécution), des registres, des magasins de variables, des poignées de fichier, des signaux, etc.

Un thread est une séquence de ces instructions dans un programme qui peut être exécutée indépendamment d'un autre code. La figure montre le concept:

Les threads se trouvent dans le même espace d'adressage de processus , ainsi, la plupart des informations présentes dans la description de la mémoire du processus peuvent être partagées entre les threads.

Certaines informations ne peuvent pas être répliquées, telles que la pile (pointeur de pile vers une zone de mémoire différente par thread), les registres et les données spécifiques au thread. Ces informations suffisent pour permettre aux threads d'être planifiés indépendamment du thread principal du programme et éventuellement d'un ou plusieurs autres threads au sein du programme.

Une prise en charge explicite du système d'exploitation est requise pour exécuter des programmes multithread. Heureusement, la plupart des systèmes d'exploitation modernes prennent en charge les threads tels que Linux (via NPTL), les variantes BSD, Mac OS X, Windows, Solaris, AIX, HP-UX, etc. Les systèmes d'exploitation peuvent utiliser différents mécanismes pour implémenter la prise en charge du multithreading.

Ici , vous pouvez trouver plus d'informations sur le sujet. C'était aussi ma source d'information.

Permettez-moi d'ajouter une phrase provenant de Introduction to Embedded System par Edward Lee et Seshia :

Les threads sont des programmes impératifs qui s'exécutent simultanément et partagent un espace mémoire. Ils peuvent accéder aux variables des autres. De nombreux praticiens dans le domaine utilisent le terme «threads» de manière plus étroite pour désigner des façons particulières de construire des programmes qui partagent la mémoire, [d'autres] pour se référer largement à tout mécanisme où les programmes impératifs s'exécutent simultanément et partagent la mémoire. Dans ce sens large, les threads existent sous forme d'interruptions sur presque tous les microprocesseurs, même sans aucun système d'exploitation (fer nu).

Les processus sont comme deux personnes utilisant deux ordinateurs différents, qui utilisent le réseau pour partager des données si nécessaire. Les threads sont comme deux personnes utilisant le même ordinateur, qui n'ont pas à partager explicitement les données mais doivent soigneusement se relayer.

Conceptuellement, les threads ne sont que plusieurs abeilles ouvrières qui bourdonnent dans le même espace d'adressage. Chaque thread a sa propre pile, son propre compteur de programmes, etc., mais tous les threads d'un processus partagent la même mémoire. Imaginez deux programmes s'exécutant en même temps, mais ils peuvent tous deux accéder aux mêmes objets.

Comparez cela aux processus. Les processus ont chacun leur propre espace d'adressage, ce qui signifie qu'un pointeur dans un processus ne peut pas être utilisé pour faire référence à un objet dans un autre (sauf si vous utilisez la mémoire partagée).

Je suppose que les éléments clés à comprendre sont:

• Les processus et les threads peuvent "s'exécuter en même temps".
• Les processus ne partagent pas la mémoire (par défaut), mais les threads partagent toute leur mémoire avec d'autres threads dans le même processus.
• Chaque thread d'un processus a sa propre pile et son propre pointeur d'instruction.

Je vais utiliser beaucoup de texte du livre Operating Systems Concepts par ABRAHAM SILBERSCHATZ, PETER BAER GALVIN et GREG GAGNE ainsi que ma propre compréhension des choses.

Processus

Toute application réside dans l'ordinateur sous forme de texte (ou code).

Nous soulignons qu'un programme en soi n'est pas un processus. Un programme est une entité passive, comme un fichier contenant une liste d'instructions stockées sur le disque (souvent appelé fichier exécutable).

Lorsque nous démarrons une application, nous créons une instance d'exécution. Cette instance d'exécution est appelée un processus. EDIT: (Selon mon interprétation, analogue à une classe et une instance d'une classe, l'instance d'une classe étant un processus.)

Un exemple de processus est celui de Google Chrome. Lorsque nous démarrons Google Chrome, 3 processus sont générés:

• Le navigateur processus du est responsable de la gestion de l'interface utilisateur ainsi que des E / S disque et réseau. Un nouveau processus de navigateur est créé au démarrage de Chrome. Un seul processus de navigateur est créé.

• Rendu processus contiennent une logique pour le rendu des pages web. Ainsi, ils contiennent la logique de gestion du HTML, du Javascript, des images, etc. En règle générale, un nouveau processus de rendu est créé pour chaque site Web ouvert dans un nouvel onglet, de sorte que plusieurs processus de rendu peuvent être actifs en même temps.

• Un processus de plug-in est créé pour chaque type de plug-in (tel que Flash ou QuickTime) utilisé. Les processus de plug-in contiennent le code du plug-in ainsi que du code supplémentaire qui permet au plug-in de communiquer avec les processus de rendu associés et le processus du navigateur.

Fil

Pour répondre à cela, je pense que vous devez d'abord savoir ce qu'est un processeur. Un processeur est la pièce matérielle qui effectue réellement les calculs. EDIT: (Les calculs comme l'ajout de deux nombres, le tri d'un tableau, essentiellement l'exécution du code qui a été écrit)

Passons maintenant à la définition d'un fil.

Un thread est une unité de base d'utilisation du CPU ; il comprend un ID de thread, un compteur de programme, un ensemble de registres et une pile.

EDIT: Définition d'un fil du site Internet d'Intel:

Un thread, ou thread d'exécution, est un terme logiciel pour la séquence ordonnée de base d'instructions qui peut être transmise ou traitée par un seul cœur de processeur.

Donc, si le processus de rendu de l'application Chrome trie un tableau de nombres, le tri aura lieu sur un thread / thread d'exécution. (La grammaire concernant les fils me semble déroutante)

Mon interprétation des choses

Un processus est une instance d'exécution. Les threads sont les travailleurs réels qui effectuent les calculs via l'accès au processeur. Lorsqu'il existe plusieurs threads en cours d'exécution pour un processus, le processus fournit une mémoire commune.

EDIT: Autres informations que j'ai trouvées utiles pour donner plus de contexte

Tous les ordinateurs modernes ont plus d'un threads. Le nombre de threads dans un ordinateur dépend du nombre de cœurs dans un ordinateur.

Calcul simultané :

De Wikipédia:

Le calcul simultané est une forme de calcul dans laquelle plusieurs calculs sont exécutés pendant des périodes qui se chevauchent - simultanément - au lieu de séquentiellement (un se terminant avant les prochains démarrages). Il s'agit d'une propriété d'un système - il peut s'agir d'un programme individuel, d'un ordinateur ou d'un réseau - et il existe un point d'exécution ou un «fil de contrôle» distinct pour chaque calcul («processus»).

Donc, je pourrais écrire un programme qui calcule la somme de 4 nombres:

(1 + 3) + (4 + 5)

Dans le programme pour calculer cette somme (qui sera un processus exécuté sur un thread d'exécution), je peux bifurquer un autre processus qui peut s'exécuter sur un autre thread pour calculer (4 + 5) et retourner le résultat au processus d'origine, tandis que le le processus d'origine calcule la somme de (1 + 3).

Malheureusement, les threads existent. Un fil est quelque chose de tangible. Vous pouvez en tuer un et les autres seront toujours en cours d'exécution. Vous pouvez générer de nouveaux threads .... bien que chaque thread ne soit pas son propre processus, ils s'exécutent séparément à l'intérieur du processus. Sur les machines multicœurs, 2 threads pouvaient s'exécuter en même temps.

http://en.wikipedia.org/wiki/Simultaneous_multithreading

http://www.intel.com/intelpress/samples/mcp_samplech01.pdf

Un thread n'est rien de plus qu'un contexte de mémoire (ou comment Tanenbaum le dit mieux, un regroupement de ressources) avec des règles d'exécution. C'est une construction logicielle. Le CPU n'a aucune idée de ce qu'est un thread (à quelques exceptions ici, certains processeurs ont des threads matériels), il exécute simplement des instructions.

Le noyau présente le concept de thread et de processus pour gérer la mémoire et l'ordre des instructions de manière significative.

Cela a été tiré d'une réponse de Yahoo:

Un thread est une construction de codage non affectée par l'architecture d'une application. Un même processus peut fréquemment contenir plusieurs threads. Les threads peuvent également communiquer directement entre eux car ils partagent les mêmes variables.

Les processus sont des unités d'exécution indépendantes avec leurs propres informations d'état. Ils utilisent également leurs propres espaces d'adressage et ne peuvent interagir avec d'autres processus que par le biais de mécanismes de communication interprocessus.

Cependant, en termes plus simples, les threads sont comme des «tâches» différentes. Alors pensez à quand vous faites quelque chose, par exemple, vous écrivez une formule sur un papier. Cela peut être considéré comme un fil. Ensuite, vous écrivez quelque chose d'autre sur une autre feuille de papier. C'est là qu'intervient le multitâche.

Les processeurs Intel auraient un «hyper-threading» (AMD aussi) et il est censé être en mesure de réaliser plusieurs «threads» ou plusieurs tâches bien mieux.

Je ne suis pas sûr de la logistique de la façon dont un fil est traité. Je me souviens avoir entendu parler du processeur entre eux, mais je ne suis pas sûr à 100% à ce sujet et j'espère que quelqu'un d'autre pourra y répondre.

La réponse varie énormément selon les différents systèmes et les différentes implémentations, mais les parties les plus importantes sont:

1. Un thread a un thread d'exécution indépendant (c'est-à-dire que vous pouvez en changer de contexte, puis revenir en arrière, et il reprendra son exécution là où il était).
2. Un thread a une durée de vie (il peut être créé par un autre thread et un autre thread peut attendre qu'il se termine).
3. Il a probablement moins de bagages attachés qu'un «processus».

Au-delà de cela: les threads peuvent être implémentés dans un seul processus par un runtime de langage, les threads peuvent être des coroutines, les threads peuvent être implémentés dans un seul processus par une bibliothèque de threads, ou les threads peuvent être une construction de noyau.

Dans plusieurs systèmes Unix modernes, y compris Linux que je connais le mieux, tout est des threads - un processus est simplement un type de thread qui partage relativement peu de choses avec son parent (c'est-à-dire qu'il obtient ses propres mappages de mémoire, sa propre table de fichiers et autorisations, etc.) La lecture man 2 clone, en particulier la liste des drapeaux, est vraiment instructive ici.

Je ne suis pas vraiment satisfait de ces réponses, donc je vais ajouter les miennes ici :) Un thread est une abstraction du noyau pour planifier le travail sur le processeur, un thread est ce que le noyau vous donne pour gérer le temps du processeur et partager le travail avec les autres

Permettez-moi d'expliquer d'abord la différence entre le processus et les threads.

Un processus peut avoir {1..N} nombre de threads. Une petite explication sur la mémoire virtuelle et le processeur virtuel.

Mémoire virtuelle

Utilisé comme espace de swap afin qu'un processus pense qu'il se trouve sur la mémoire principale pour l'exécution.

Processeur virtuel

Le même concept que la mémoire virtuelle sauf pour le processeur. Pour un processus, il semblera que c'est la seule chose qui utilise le processeur.

Le système d'exploitation veillera à allouer la mémoire virtuelle et le processeur virtuel à un processus et à effectuer l'échange entre les processus et à effectuer l'exécution.

Tous les threads d'un processus partageront la même mémoire virtuelle. Mais, chaque thread se verra attribuer son processeur virtuel individuel afin qu'il puisse être exécuté individuellement.

Ainsi, la mémoire ainsi que l'utilisation du processeur à son potentiel.