Énumération COINIT (objbase.h)

Article
02/29/2024

Détermine le modèle d’accès concurrentiel utilisé pour les appels entrants aux objets créés par ce thread. Ce modèle d’accès concurrentiel peut être soit en thread d’appartement, soit multithread.

Syntax

typedef enum tagCOINIT {
  COINIT_APARTMENTTHREADED = 0x2,
  COINIT_MULTITHREADED = 0x0,
  COINIT_DISABLE_OLE1DDE = 0x4,
  COINIT_SPEED_OVER_MEMORY = 0x8
} COINIT;

Constantes


`COINIT_APARTMENTTHREADED` Valeur : 0x2 Initialise le thread pour la concurrence des objets apartment-threaded (voir Remarques).
`COINIT_MULTITHREADED` Valeur : 0x0 Initialise le thread pour la concurrence d’objets multithread (voir Remarques).
`COINIT_DISABLE_OLE1DDE` Valeur : 0x4 Désactive DDE pour la prise en charge d’OLE1.
`COINIT_SPEED_OVER_MEMORY` Valeur : 0x8 Augmentez l’utilisation de la mémoire pour tenter d’augmenter les performances.

Remarques

Lorsqu’un thread est initialisé via un appel à CoInitializeEx, vous choisissez de l’initialiser en tant que thread d’appartement ou multithread en désignant l’un des membres de COINIT comme deuxième paramètre. Cela désigne la façon dont les appels entrants à n’importe quel objet créé par ce thread sont gérés, c’est-à-dire la concurrence de l’objet.

Le thread d’appartement, tout en autorisant l’exécution de plusieurs threads, sérialise tous les appels entrants en exigeant que les appels aux méthodes d’objets créés par ce thread s’exécutent toujours sur le même thread, c’est-à-dire l’appartement/le thread qui les a créés. En outre, les appels ne peuvent arriver qu’aux limites de la file d’attente de messages. En raison de cette sérialisation, il n’est généralement pas nécessaire d’écrire le contrôle d’accès concurrentiel dans le code de l’objet, sauf pour éviter les appels à PeekMessage et SendMessage pendant le traitement qui ne doivent pas être interrompus par d’autres appels de méthode ou d’autres objets dans le même appartement/thread.

Le multithreading (également appelé free-threading) permet d’exécuter des appels aux méthodes d’objets créés par ce thread sur n’importe quel thread. Il n’y a pas de sérialisation des appels, c’est-à-dire que de nombreux appels peuvent se produire à la même méthode ou au même objet ou simultanément. La concurrence d’objets multithread offre les performances les plus élevées et tire le meilleur parti du matériel multiprocesseur pour les appels inter-threads, interprocessus et inter-ordinateurs, car les appels aux objets ne sont en aucun cas sérialisés. Cela signifie toutefois que le code des objets doit appliquer son propre modèle d’accès concurrentiel, généralement à l’aide de primitives de synchronisation, telles que des sections critiques, des sémaphores ou des mutex. En outre, étant donné que l’objet ne contrôle pas la durée de vie des threads qui y accèdent, aucun état spécifique au thread ne peut être stocké dans l’objet (dans Stockage local thread).

Note L’appartement multithread est destiné à être utilisé par des threads non-GUI. Les threads dans les appartements multithread ne doivent pas effectuer d’actions d’interface utilisateur. En effet, les threads d’interface utilisateur nécessitent une pompe de messages et COM ne pompe pas les messages pour les threads dans un appartement multithread.

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Windows 2000 Professionnel [applications de bureau uniquement]
Serveur minimal pris en charge	Windows 2000 Server [applications de bureau uniquement]
En-tête	objbase.h

Voir aussi

CoInitializeEx

IInitializeSpy ::P ostInitialize

IInitializeSpy ::P reInitialize

Processus, threads et appartements

Partager via