Thread (informatique)

Un thread ou fil (d'exécution) ou tâche (terme et définition normalisés par ISO/IEC 2382-7:2000 ; autres appellations connues : processus léger, unité de traitement, unité d'exécution, fil d'instruction, processus allégé, exétron), est similaire à un processus car tous deux représentent l'exécution d'un ensemble d'instructions du langage machine d'un processeur. Du point de vue de l'utilisateur, ces exécutions semblent se dérouler en parallèle. Toutefois, là où chaque processus possède sa propre mémoire virtuelle, les threads d'un même processus se partagent sa mémoire virtuelle. Par contre, tous les threads possèdent leur propre pile d’appel.

Les threads ou tâches sont typiquement utilisés avec l'interface graphique ("GUI") d'un programme. En effet, les interactions de l'utilisateur avec le processus, par l'intermédiaire des périphériques d'entrée, sont gérées par un thread, tandis que les calculs lourds (en termes de temps de calcul) sont gérés par un ou plusieurs autres threads. Cette technique de conception de logiciel est avantageuse dans ce cas, car l'utilisateur peut continuer d'interagir avec le programme même lorsque celui-ci est en train d'exécuter une tâche. Une application pratique se retrouve dans les traitements de texte où la correction orthographique est exécutée tout en permettant à l'utilisateur de continuer à entrer son texte.

L'utilisation des threads permet donc de rendre l'utilisation d'une application plus fluide, car il n'y a plus de blocage durant les phases de traitements intenses.

Les threads se distinguent du multi-processus plus classique par le fait que deux processus sont typiquement indépendants et peuvent interagir uniquement à travers une API fournie par le système telle que IPC. D'un autre côté les threads partagent une information sur l'état du processus, des zones de mémoires ainsi que d'autres ressources. Puisqu'il n'y a pas de changement de mémoire virtuelle, la commutation de contexte (context switch) entre deux threads est moins coûteuse que la commutation de contexte entre deux processus. On peut y voir un avantage de la programmation utilisant des threads multiples.

Dans certains cas, les programmes utilisant des threads sont plus rapides que des programmes architecturés plus classiquement, en particulier sur les machines comportant plusieurs processeurs. Hormis le problème du coût de la commutation de contexte, le principal surcoût dû à l'utilisation de processus multiples provient de la communication entre processus séparés. En effet, le partage de certaines ressources entre threads permet une communication plus efficace entre les différents threads d'un processus. Là où deux processus séparés doivent utiliser un mécanisme fourni par le système pour communiquer, les threads partagent une partie de l'état du processus.

La programmation utilisant des threads est toutefois plus difficile, et l'accès à certaines ressources partagées doit être restreint par le programme lui-même, pour éviter que l'état d'un processus ne devienne temporairement incohérent, tandis qu'un autre thread va avoir besoin de consulter cette portion de l'état du processus. Il est donc obligatoire de mettre en place des mécanismes de synchronisation (à l'aide de sémaphores par exemple), tout en conservant à l'esprit que l'utilisation de la synchronisation peut aboutir à des situations d'interblocage. La complexité des programmes utilisant des threads est aussi nettement plus grande que celle des programmes déférant le travail à faire à plusieurs processus plus simples. Cette complexité accrue, lorsqu'elle est mal gérée lors de la phase de conception ou de mise en œuvre d'un programme, peut conduire à de multiples problèmes.

Les systèmes d'exploitation mettent en œuvre généralement les threads.

Certains langages de programmation, tels que Smalltalk et certaines implémentations de Java, intégrent un support pour les threads implémentés dans l'espace utilisateur (green threads), indépendamment des capacités du système d'exploitation hôte. La plupart des langages (Java sur la plupart des systèmes d'exploitation, C# .NET, Ruby, ...) utilisent des extensions du langage ou des bibliothèques pour utiliser directement les services de multithreading du système d'exploitation, mais de façon portable (threads natifs). Enfin, des langages comme Haskell utilisent un système hybride à mi-chemin entre les deux approches. A noter que, pour des raisons de performances en fonction des besoins, la plupart des langages permettent d'utiliser au choix des threads natifs ou des green threads (notamment via l'utilisation de fibres).

En programmation orientée objet on parle de classe réentrante lorsque des instances distinctes de cette classe peuvent exister simultanément dans différents threads.

Il ne faut pas confondre la technologie Hyperthreading incluse dans certains processeurs Intel avec les threads. Cette technologie permet en effet aussi bien l'exécution simultanée de processus distincts que de threads. Toute machine comportant des processeurs multiples (SMP) ou des processeurs intégrant l'HyperThreading permet l'exécution plus rapide de programmes utilisant des threads aussi bien que des processus multiples.