Partager via

Processus, threads et appartements

Un processus est une collection d’espace de mémoire virtuelle, 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, donc 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 RPC (Remote Procedure Call) de Microsoft pour transmettre des informations les unes aux autres. Il n’existe aucune différence avec 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 threads 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 et ressources globales du processus.

Le planificateur de threads détermine quand et la fréquence d’exécution d’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 threading : les interblocages et les conditions de concurrence. Un interblocage se produit lorsque chaque thread attend que l’autre fasse quelque chose. Le contrôle d’appel COM permet d’empêcher les interblocages entre les objets. Une condition de compétition se produit lorsqu’un thread se termine avant un autre dont il dépend, ce qui conduit à l'utilisation d'une valeur non initialisée, car le second 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. (Consultez les assistants d'implémentation de serveur hors processus.)

L’appartement et l’architecture de gestion des threads COM

Bien que COM prenne en charge le modèle monothread 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 entraîne une exécution plus efficace des applications, en permettant à un thread d’être exécuté pendant qu’un autre thread attend une opération fastidieuse.

Remarque

L’utilisation de plusieurs threads n’est pas une garantie de meilleures performances. En fait, étant donné que le facteur de thread est un problème difficile, l’utilisation de plusieurs threads provoque 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, la façon la plus simple de comprendre l’architecture de thread COM est de 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 être directement appelées directement par un fil qui appartient à cet appartement. Tout autre thread qui souhaite appeler l’objet doit passer par un proxy.

Il existe deux types d’appartements : appartements monofil et appartements multithreading.

  • Les appartements à thread unique se composent exactement d’un thread, donc tous les objets COM qui vivent dans un appartement à thread unique peuvent recevoir des appels de méthode uniquement à 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 du thread de cet 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, de sorte que tous les objets COM qui vivent dans un appartement multithread peuvent recevoir des appels de méthode directement à partir de l’un des threads appartenant à l’appartement multithread. Les threads d’un appartement multithread utilisent un modèle appelé free-threading. Les appels aux objets COM d’un appartement multithread sont synchronisés par les objets eux-mêmes.

Remarque

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

 

Un processus peut avoir zéro ou plusieurs appartements à un seul thread et zéro ou un appartement à multiples threads.

Dans un processus, l’appartement principal est le premier à être initialisé. Dans un processus à thread unique, il s’agit du seul appartement. Les paramètres d’appel sont encapsulés entre les appartements, et COM gère la synchronisation via la messagerie. Si vous désignez plusieurs threads dans un processus à threads libres, tous les threads libres résident dans un seul appartement, les paramètres sont transmis directement à n’importe quel thread de l’appartement, et vous devez gérer toutes les synchronisations. Dans un processus avec threading libre et thread d’appartement, tous les threads libres résident dans un seul appartement et tous les autres appartements sont des appartements à thread unique. Un processus qui effectue des travaux COM est une collection d'appartements avec, au plus, un appartement multithreadé mais n'importe quel nombre d'appartements à un seul thread.

Les modèles de thread dans COM fournissent le mécanisme pour les clients et les serveurs qui utilisent différentes architectures de threading pour travailler ensemble. Les appels entre les objets avec différents modèles de threading dans différents processus sont naturellement pris en charge. Du point de vue de l’objet appelant, tous les appels à des objets en dehors d’un processus se comportent de façon identique, quel que soit le mode d’appel de l’objet. De même, du point de vue de l’objet appelé, les appels arrivants se comportent de façon 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 lorsqu’ils utilisent différents modèles de thread, car le client et l’objet se trouvent dans différents processus. COM, interposé entre le client et le serveur, peut fournir le code pour que les modèles de threading interopèrent, à l’aide de la marshalisation standard et du RPC. Par exemple, si un objet à thread unique est appelé simultanément par plusieurs clients threads libres, 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, certaines précautions doivent être prises pour s’assurer que les serveurs in-process interagissent correctement avec leurs clients. (Consultez In-Process problèmes de thread de serveur.)

Le problème le plus important dans la programmation avec un modèle multithread consiste à rendre votre thread de code sécurisé afin que les messages destinés à un thread particulier ne passent qu’à ce thread et que l’accès aux threads soit protégé.

Pour plus d’informations, consultez les rubriques suivantes :

 

 

  • Last updated on