Thread (informatique)

Les threads sont classiquement utilisés avec l'interface graphique (Graphical user interface) d'un programme, pour des attentes asynchrones dans les télécommunications ou encore pour des programmes de calcul intensif (comme l'encodage d'une vidéo, les simulations mathématiques, etc.).

En effet, dans le cas d'une interface graphique, 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, technique similaire à celle utilisée pour les attentes asynchrones, 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.

Dans le cas d'un programme de calcul intensif, l'utilisation de plusieurs threads permet de paralléliser le traitement, ce qui, sur les machines multiprocesseur, permet de l'effectuer bien plus rapidement.

Deux processus sont totalement indépendants et isolés l'un de l'autre. Ils ne peuvent interagir qu'à travers une API fournie par le système, telle qu'IPC, tandis que les threads partagent une information sur l'état du processus, des zones de mémoires, ainsi que d'autres ressources. En fait, à part leur pile d’appel, des mécanismes comme le Thread Local Storage et quelques rares exceptions spécifiques à chaque implémentation, les threads partagent tout. 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 en temps 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 ressources entre threads permet une communication plus efficace entre les différents threads d'un processus qu'entre deux processus distincts. 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, notamment sa mémoire. Dans le cas de données en lecture seule, il n'y a même pas besoin du moindre mécanisme de synchronisation pour que les threads utilisent les mêmes données.

La programmation utilisant des threads est toutefois plus rigoureuse que la programmation séquentielle, 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 si elle est mal utilisée.

La complexité des programmes utilisant des threads est aussi nettement plus grande que celle des programmes déférant séquentiellement le travail à faire à plusieurs processus plus simples (la complexité est similaire dans le cas de plusieurs processus travaillant en parallèle). 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 tels que :

• Interblocages apparemment aléatoires :
  • Si un algorithme est mal conçu et permet un interblocage, le changement de vitesse du processeur, par l'utilisation incomplète d'un quantum de temps alloué ou au contraire de la nécessité d'utiliser un quantum supplémentaire, peut provoquer la situation d'interblocage,
  • De même, des périphériques plus ou moins rapides que ceux de la machine ayant servi à développer/tester le programme induisent des synchronisations temporellement différentes, et donc peuvent provoquer un interblocage non détecté auparavant,
  • Enfin, le changement de charge processeur de la machine (un programme lourd tournant en parallèle, par exemple) peut là aussi déclencher plus facilement des interblocages qui n'avaient pas été vus auparavant, avec l'illusion d'un phénomène aléatoire ;
• Complexification inutile de certains algorithmes, qui ne bénéficient pas de la parallélisation du code mais qui sont pénalisés par des synchronisations d'accès aux ressources partagées :
  • Sur-parallélisation du code alors qu'un traitement séquentiel serait plus adapté, la perte de temps liée à la commutation de contexte n'étant pas compensée par la parallélisation,
  • Introduction de variables globales, forçant l'utilisation de synchronisation à outrance et donc des commutations de contexte inutiles ;
• Sur-utilisation des mécanismes de synchronisation inadaptés là où ils ne sont pas nécessaires, induisant un surcoût de temps processeur inutile :
  • La mise en œuvre d'un pipeline FIFO entre deux threads seulement peut être effectuée facilement sans aucun mutex,
  • Utilisation d'une section critique au lieu d'un mutex lecteurs/rédacteur, par exemple lorsque beaucoup de threads lisent une donnée tandis que peu écrivent dedans ou qu'une donnée est plus souvent lue qu'écrite.

Beaucoup de patterns peuvent bénéficier des threads, comme Decorator, Factory Method, Command ou encore Proxy. De manière générale, toute passation d'information à une entité logicielle d'un pattern peut faire l'objet de l'utilisation de threads.

Parmi les autres exemples classiques, on trouve :

• Modèles maître-esclave et client-serveur :
  • Un thread « maître » centralise le travail à faire et le distribue aux threads « esclaves », collectant ensuite leurs résultats.
  • Un pool de threads (le pool étant statique ou dynamique) permet d'interroger plusieurs serveurs sans bloquer le client.
  • Le Pair à pair (Peer-to-peer) est un modèle similaire au maître-esclave, mais où le thread maître n'est pas figé (chaque thread est le maître de tous les autres, tout en étant esclave lui-même).
• Pipeline :
  • La tâche est découpée en diverses étapes successives et/ou opérations unitaires. Chaque thread réalise une des étapes et passe son résultat au suivant.
  • Plusieurs pipelines peuvent coexister afin d'accélérer encore le traitement.
  • Des traitements comme la compilation, le streaming, le traitement multimédia (décodage de vidéos par exemple) bénéficient fortement d'une implémentation utilisant des threads.

Il ne faut pas confondre la technologie Hyper-Threading de 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’Hyper-Threading permet aussi bien l'exécution plus rapide de programmes utilisant des threads que de multiples processus.