Tutorial d'initiation
A la programmation avec l'API Windows

Chapitre 5

Le multithreading

14. Performances

La création d'applications multithread est généralement très performante. Toutefois, il faudra faire attention à préserver les performances systèmes. La synchronisation devra toujours être effectuées grâce aux objets fournis par l'API comme les sections critiques, les événements ou encore les sémaphores. Il faut toujours penser qu'un thread inactif doit laisser le contrôle au système et non pas effectuer une boucle. Bien qu'elles fonctionnent parfaitement, les boucles sont désastreuses au niveau performances système et on perd rapidement l'intérêt de l'application multithread.

Il ne faut pas non plus tenter de segmenter à tout prix les tâches. Un nombre trop important de threads peut nuire aux performances système. Le travail qui peut être effectué par un thread ne doit donc pas être confié à 2 threads.

Les applications clients réseau sont souvent très performantes grâce au multithreading. En effet, le fait d'établir plusieurs connections avec la machine hôte permet d'améliorer le débit réseau. Toutefois, un nombre trop important de threads finira par nuire aux performances de l'application car le système perd du temps en passant le contrôle du processeur à un nombre trop important de threads. Les applications sont alors considérablement ralenties.

De plus, la réalisation d'applications multithread est souvent source d'erreurs. En effet, il ne faut jamais oublier que des instructions situées dans des threads seront exécutées dans un ordre quelconque. Il ne faut jamais tenter de prévoir l'ordre d'exécution. A partir du moment où l'ordre d'exécution n'est pas certain, il faudra impérativement utiliser les fonctions de synchronisation.

Il faut également comprendre que le fait d'utiliser des fonctions de synchronisation nuit aux performances de l'application. Les fonctions de synchronisation ne doivent donc pas être utilisées si elles ne sont pas nécessaires. De plus, si un nombre important de threads partage des données, le temps d'attente pour obtenir l'accès à ces données va rapidement devenir important. Chaque thread passera donc un temps important à attendre, ce qui est d'autant plus problématique si la tâche qu'il doit effectuer est courte.

Il faut également éviter impérativement des entrées - sorties successives dans des sections critiques. En effet, si le temps d'exécution entre les sections critiques est trop court, le thread aura très rapidement un temps d'attente supérieur à son temps de calcul. Ce problème se manifestera encore plus avec un nombre important de threads. Si un thread doit faire des accès successifs à des données partagées, il peut copier ces données dans un espace non partagé ou rester dans la section critique le temps d'exécuter sa tâche. Si le temps d'exécution de la tâche est court, un thread aura tout intérêt à ne pas sortir de la section critique.

Il faut donc impérativement prendre en compte les questions de performance lors de la réalisation d'applications multithread. De plus, les plantages dus à des problèmes de partage de données ne surviendront pas forcément lors des tests car les threads ne s'exécutent jamais de la même manière. Il faut donc prévoir les problèmes de partage et non pas compter sur les tests pour les déceler.