Fil (informatique)

Les fibres constituent une unité d'ordonnancement encore plus légère, à ordonnancement coopératif : une fibre en cours d'exécution doit explicitement céder la place à une autre, ce qui simplifie considérablement leur implémentation par rapport aux threads noyau ou utilisateur . Une fibre peut être exécutée dans n'importe quel thread du même processus. Ceci permet aux applications d'améliorer leurs performances en gérant elles-mêmes leur ordonnancement, au lieu de dépendre de l'ordonnanceur du noyau (qui peut ne pas être optimisé pour l'application). Certaines implémentations de recherche du modèle de programmation parallèle OpenMP utilisent des fibres pour leurs tâches. Les coroutines sont étroitement liées aux fibres , la différence étant que les coroutines sont une construction de niveau langage, tandis que les fibres sont une construction de niveau système.

Les threads diffèrent des processus multitâches traditionnels des systèmes d'exploitation à plusieurs égards :

• Les processus sont généralement indépendants, tandis que les threads existent en tant que sous-ensembles d'un processus.
• Les processus contiennent beaucoup plus d'informations d'état que les threads, tandis que plusieurs threads au sein d'un même processus partagent l'état du processus ainsi que la mémoire et d'autres ressources.
• Les processus possèdent des espaces d'adressage distincts , tandis que les threads partagent leur espace d'adressage.
• Les processus interagissent uniquement par le biais de mécanismes de communication interprocessus fournis par le système.
• Le changement de contexte entre les threads d'un même processus est généralement plus rapide que le changement de contexte entre les processus.

Les systèmes tels que Windows NT et OS/2 sont réputés pour leurs threads bon marché et leurs processus coûteux ; dans d'autres systèmes d'exploitation, la différence n'est pas aussi grande, sauf en ce qui concerne le coût d'un changement d'espace d'adressage , qui sur certaines architectures (notamment x86 ) entraîne une vidange du tampon de traduction (TLB).

Les avantages et les inconvénients des threads par rapport aux processus sont les suivants :

• Consommation réduite de ressources grâce aux threads : en utilisant des threads, une application peut fonctionner en utilisant moins de ressources qu’avec plusieurs processus.
• Partage et communication simplifiés des threads : contrairement aux processus, qui nécessitent un mécanisme de passage de messages ou de mémoire partagée pour effectuer une communication interprocessus (IPC), les threads peuvent communiquer via les données, le code et les fichiers qu’ils partagent déjà.
• Un thread peut faire planter un processus : comme les threads partagent le même espace d’adressage, une opération illégale effectuée par un thread peut faire planter l’ensemble du processus ; par conséquent, un thread défaillant peut perturber le traitement de tous les autres threads de l’application.

Les systèmes d'exploitation planifient les threads de manière préemptive ou coopérative . Les systèmes d'exploitation multi-utilisateurs privilégient généralement le multithreading préemptif pour son contrôle plus précis du temps d'exécution grâce aux changements de contexte . Cependant, la planification préemptive peut entraîner des changements de contexte imprévus, provoquant ainsi des conflits de verrouillage , des inversions de priorité ou d'autres effets indésirables. À l'inverse, le multithreading coopératif repose sur la capacité des threads à céder le contrôle de l'exécution, garantissant ainsi leur exécution complète . Cela peut poser problème si un thread multitâche coopératif se bloque en attendant une ressource ou s'il prive d'autres threads de ressources en ne cédant pas le contrôle de l'exécution lors de calculs intensifs.

Jusqu'au début des années 2000, la plupart des ordinateurs de bureau ne disposaient que d'un seul processeur monocœur, sans prise en charge du multithreading matériel . Cependant, le multithreading était encore utilisé sur ces machines car le passage d'un thread à l'autre était généralement plus rapide que les changements de contexte complets . En 2002, Intel a intégré la prise en charge du multithreading simultané au processeur Pentium 4 , sous le nom d' Hyper-Threading ; en 2005, Intel a lancé le processeur bicœur Pentium D et AMD le processeur bicœur Athlon 64 X2 .

Les systèmes monoprocesseurs implémentent généralement le multithreading par répartition temporelle : l’ unité centrale de traitement (CPU) alterne entre différents threads logiciels . Ce changement de contexte est généralement suffisamment fréquent pour que les utilisateurs perçoivent l’exécution des threads ou des tâches comme étant en parallèle (sur les systèmes d’exploitation serveur/poste de travail courants, la durée maximale d’exécution d’un thread, lorsque d’autres threads sont en attente, est souvent limitée à 100–200 ms). Sur un système multiprocesseur ou multicœur , plusieurs threads peuvent s’exécuter en parallèle , chaque processeur ou cœur exécutant un thread distinct simultanément ; sur un processeur ou un cœur doté de threads matériels , des threads logiciels distincts peuvent également être exécutés simultanément par des threads matériels distincts.

Les threads d'un même processus partagent le même espace d'adressage. Cela permet à du code exécuté simultanément de s'exécuter de manière étroite et d'échanger des données facilement, sans la surcharge ni la complexité d'un IPC (Interface de Processus ). Cependant, lorsqu'elles sont partagées entre les threads, même des structures de données simples deviennent sujettes à des conditions de concurrence si leur mise à jour nécessite plus d'une instruction CPU : deux threads peuvent tenter de mettre à jour la structure de données simultanément et constater qu'elle est modifiée de manière inattendue. Les bogues causés par des conditions de concurrence peuvent être très difficiles à reproduire et à isoler.

Pour éviter cela, les interfaces de programmation d'applications (API) multithread offrent des primitives de synchronisation, comme les mutex, pour verrouiller les structures de données et empêcher les accès concurrents. Sur les systèmes monoprocesseurs, un thread accédant à un mutex verrouillé doit se mettre en veille, ce qui provoque un changement de contexte. Sur les systèmes multiprocesseurs, le thread peut interroger le mutex via un verrouillage par attente active ( spinlock ). Ces deux méthodes peuvent dégrader les performances et contraindre les processeurs des systèmes multiprocesseurs symétriques (SMP) à se disputer le bus mémoire, surtout si la granularité du verrouillage est trop fine.

D'autres API de synchronisation incluent les variables de condition , les sections critiques , les sémaphores et les moniteurs .