Partager via

Processus, threads et appartements

  • Article

Un processus est une collection d’espace mémoire virtuel, de code, de données et de ressources système. Un thread est du code qui doit être exécuté en série dans un processus. Un processeur exécute des threads, et non des processus, de sorte que chaque application a au moins un processus, et un processus a toujours au moins un thread d’exécution, appelé thread principal. Un processus peut avoir plusieurs threads en plus du thread principal.

Les processus communiquent entre eux par le biais de messages, à l’aide de la technologie d’appel de procédure distante (RPC) de Microsoft pour se transmettre des informations. Il n’y a aucune différence pour l’appelant entre un appel provenant d’un processus sur un ordinateur distant et un appel provenant d’un autre processus sur le même ordinateur.

Lorsqu’un thread commence à s’exécuter, il continue jusqu’à ce qu’il soit tué ou jusqu’à ce qu’il soit interrompu par un thread avec une priorité plus élevée (par une action utilisateur ou le planificateur de thread du noyau). Chaque thread peut exécuter des sections distinctes de code, ou plusieurs threads peuvent exécuter la même section de code. Les threads exécutant le même bloc de code gèrent des piles distinctes. Chaque thread d’un processus partage les variables globales et les ressources de ce processus.

Le planificateur de thread détermine quand et à quelle fréquence exécuter un thread, en fonction d’une combinaison de l’attribut de classe de priorité du processus et de la priorité de base du thread. Vous définissez l’attribut de classe de priorité d’un processus en appelant la fonction SetPriorityClass et vous définissez la priorité de base d’un thread avec un appel à SetThreadPriority.

Les applications multithread doivent éviter deux problèmes de thread : les interblocages et lescourses. Un interblocage se produit lorsque chaque thread attend que l’autre fasse quelque chose. Le contrôle d’appel COM permet d’éviter les interblocages dans les appels entre les objets. Une condition de concurrence se produit lorsqu’un thread se termine avant un autre dont il dépend, ce qui amène le premier à utiliser une valeur non initialisée, car cette dernière n’a pas encore fourni de valeur valide. COM fournit certaines fonctions spécifiquement conçues pour éviter les conditions de concurrence dans les serveurs hors processus. (Voir Assistances sur l’implémentation de serveur hors processus.)

L’appartement et l’architecture de thread com

Bien que COM prenne en charge le modèle mono thread par processus répandu avant l’introduction de plusieurs threads d’exécution, vous pouvez écrire du code pour tirer parti de plusieurs threads, ce qui permet des applications plus efficaces, en autorisant l’exécution d’un thread pendant qu’un autre thread attend la fin d’une opération fastidieuse.

Notes

L’utilisation de plusieurs threads n’est pas une garantie de meilleures performances. En fait, étant donné que la factoring des threads est un problème difficile, l’utilisation de plusieurs threads entraîne souvent des problèmes de performances. La clé consiste à utiliser plusieurs threads uniquement si vous êtes très sûr de ce que vous faites.

 

En général, le moyen le plus simple d’afficher l’architecture de thread COM consiste à considérer tous les objets COM du processus comme divisés en groupes appelés appartements. Un objet COM vit exactement dans un seul appartement, dans le sens où ses méthodes peuvent légalement être appelées directement uniquement par un thread qui appartient à cet appartement. Tout autre thread qui souhaite appeler l’objet doit passer par un proxy.

Il existe deux types d’appartements : les appartements à thread unique et les appartements multithread.

  • Les appartements à thread unique se composent d’un seul thread, de sorte que tous les objets COM qui vivent dans un appartement à thread unique ne peuvent recevoir des appels de méthode qu’à partir du seul thread qui appartient à cet appartement. Tous les appels de méthode à un objet COM dans un appartement à thread unique sont synchronisés avec la file d’attente de messages Windows pour le thread de l’appartement à thread unique. Un processus avec un seul thread d’exécution est simplement un cas spécial de ce modèle.
  • Les appartements multithreads se composent d’un ou plusieurs threads. Ainsi, tous les objets COM qui vivent dans un appartement multithread peuvent recevoir des appels de méthode directement de l’un des threads qui appartiennent à l’appartement multithread. Les threads dans un appartement multithread utilisent un modèle appelé free-threading. Les appels aux objets COM dans un appartement multithread sont synchronisés par les objets eux-mêmes.

Notes

Pour obtenir une description de la communication entre les appartements à thread unique et les appartements multithreads au sein du même processus, consultez Communication à thread unique et multithread.

 

Un processus peut avoir zéro ou plusieurs appartements à thread unique et zéro ou un appartement multithread.

Dans un processus, l’appartement main est le premier à être initialisé. Dans un processus à thread unique, il s’agit du seul appartement. Les paramètres d’appel sont marshalés entre les appartements et COM gère la synchronisation via la messagerie. Si vous désignez plusieurs threads dans un processus à thread libre, tous les threads libres résident dans un seul appartement, les paramètres sont passés directement à n’importe quel thread dans l’appartement et vous devez gérer toute la synchronisation. Dans un processus avec à la fois le thread libre et le thread d’appartement, tous les threads gratuits résident dans un seul appartement et tous les autres appartements sont des appartements à thread unique. Un processus qui fonctionne com est une collection d’appartements avec, au plus, un appartement multithread mais un nombre quelconque d’appartements monothread.

Les modèles de thread dans COM fournissent le mécanisme permettant aux clients et aux serveurs qui utilisent différentes architectures de thread de fonctionner ensemble. Les appels entre objets avec différents modèles de thread dans différents processus sont naturellement pris en charge. Du point de vue de l’objet appelant, tous les appels aux objets en dehors d’un processus se comportent de façon identique, quelle que soit la façon dont l’objet appelé est threadé. De même, du point de vue de l’objet appelé, les appels arrivants se comportent de manière identique, quel que soit le modèle de thread de l’appelant.

L’interaction entre un client et un objet hors processus est simple, même quand ils utilisent différents modèles de thread, car le client et l’objet se trouvent dans des processus différents. COM, interposé entre le client et le serveur, peut fournir le code permettant aux modèles de thread d’interagir, à l’aide du marshaling standard et du RPC. Par exemple, si un objet à thread unique est appelé simultanément par plusieurs clients à thread libre, les appels sont synchronisés par COM en plaçant les messages de fenêtre correspondants dans la file d’attente des messages du serveur. L’appartement de l’objet reçoit un appel chaque fois qu’il récupère et distribue des messages. Toutefois, il faut veiller à ce que les serveurs in-process interagissent correctement avec leurs clients. (Consultez Problèmes de thread de serveur in-process.)

Le problème le plus important dans la programmation avec un modèle multithread est de sécuriser votre thread de code afin que les messages destinés à un thread particulier soient envoyés uniquement à ce thread et que l’accès aux threads soit protégé.

Pour plus d'informations, voir les rubriques suivantes :