Question

Pouvez-vous expliquer STA et MTA avec vos propres mots?

De plus, quels sont les threads d'appartement et ne concernent-ils que COM? Si oui, pourquoi?

Était-ce utile?

La solution

Le modèle de threading COM est appelé "appartement". modèle, où le contexte d'exécution des objets COM initialisés est associé à un seul thread (appartement à thread unique) ou à plusieurs threads (appartement à threads multiples). Dans ce modèle, un objet COM, une fois initialisé dans un appartement, en fait partie pendant toute la durée de son exécution.

Le modèle STA est utilisé pour les objets COM qui ne sont pas thread-safe. Cela signifie qu'ils ne gèrent pas leur propre synchronisation. Une utilisation courante de ceci est un composant d'interface utilisateur. Ainsi, si un autre thread doit interagir avec l'objet (par exemple, appuyer sur un bouton dans un formulaire), le message est alors organisé sur le thread STA. Le système de pompage de messages Windows Forms en est un exemple.

Si l'objet COM peut gérer sa propre synchronisation, le modèle MTA peut être utilisé lorsque plusieurs threads sont autorisés à interagir avec l'objet sans appels organisés.

Autres conseils

Tout dépend de la manière dont les appels aux objets sont gérés et de la protection dont ils ont besoin. Les objets COM peuvent demander au moteur d'exécution de les protéger contre les appels simultanés de plusieurs threads. ceux qui ne le peuvent pas peuvent potentiellement être appelés simultanément de différents threads, ils doivent donc protéger leurs propres données.

De plus, il est également nécessaire que le moteur d'exécution empêche un appel d'objet COM de bloquer l'interface utilisateur, si un appel est effectué à partir d'un thread d'interface utilisateur.

Un appartement est un lieu de vie d'objets, qui contiennent un ou plusieurs threads. L'appartement définit ce qui se passe lorsque des appels sont effectués. Les appels d’objets dans un appartement seront reçus et traités sur n’importe quel fil de cet appartement, à l’exception qu’un appel d’un fil déjà présent dans le bon appartement sera traité par lui-même (c’est-à-dire un appel direct à l’objet).

Les fils peuvent être soit dans un appartement à un seul fil (dans ce cas, ils sont le seul fil de cet appartement), soit dans un appartement à plusieurs fils. Ils spécifient à quel moment le thread initialise COM pour ce thread.

La STA est principalement destinée à la compatibilité avec l'interface utilisateur, qui est liée à un thread spécifique. Un STA reçoit des notifications d'appels à traiter en recevant un message de fenêtre dans une fenêtre cachée; lorsqu'il effectue un appel sortant, il commence une boucle de messages modale pour empêcher le traitement d'autres messages de fenêtre. Vous pouvez spécifier un filtre de messages à appeler afin que votre application puisse répondre à d'autres messages.

En revanche, tous les threads MTA partagent un seul MTA pour le processus. COM peut démarrer un nouveau thread de travail pour gérer un appel entrant si aucun thread n'est disponible, jusqu'à une limite de pool. Les fils effectuant des appels sortants sont simplement bloqués.

Par souci de simplicité, nous ne considérerons que les objets implémentés dans les DLL, qui publient dans le registre ce qu’ils gèrent, en définissant la valeur ThreadingModel pour la clé de leur classe. Il y a quatre options:

  • Filetage principal (valeur ThreadingModel non présente). L'objet est créé sur le thread d'interface utilisateur principal de l'hôte et tous les appels sont organisés vers ce thread. La fabrique de classes ne sera appelée que sur ce thread.
  • Appartement . Cela indique que la classe peut s'exécuter sur n'importe quel thread en mode mono-thread. Si le thread qui le crée est un thread STA, l'objet s'exécutera sur ce thread. Dans le cas contraire, il sera créé dans le STA principal. S'il n'existe aucun STA principal, un thread STA est créé pour celui-ci. (Cela signifie que les threads MTA qui créent des objets Apartment organiseront tous les appels à un thread différent.) La fabrique de classes peut être appelée simultanément par plusieurs threads STA. Elle doit donc protéger ses données internes.
  • Gratuit . Cela indique une classe conçue pour s'exécuter dans le MTA. Il sera toujours chargé dans le MTA, même s'il est créé par un thread STA, ce qui signifie à nouveau que les appels du thread STA seront marshallés. En effet, un objet Free est généralement écrit dans l’espoir qu’il peut bloquer.
  • Les deux . Ces classes sont flexibles et se chargent dans n'importe quel appartement à partir duquel elles ont été créées. Cependant, ils doivent être écrits pour répondre aux deux ensembles d'exigences: ils doivent protéger leur état interne contre les appels simultanés, au cas où ils sont chargés dans le MTA, mais ne doivent pas bloquer, s'ils sont chargés dans un STA.

À partir du .NET Framework, utilisez simplement [STAThread] sur tout thread qui crée une interface utilisateur. Les threads de travail doivent utiliser le MTA, à moins qu'ils n'utilisent des composants COM marqués Apartment . Dans ce cas, utilisez la STA pour éviter les problèmes de surcharge et d'évolutivité si le même composant est appelé à partir de plusieurs threads ( chaque thread devra attendre le composant à son tour). C’est beaucoup plus simple si vous utilisez un objet COM distinct par thread, que le composant soit dans le STA ou le MTA.

Je trouve les explications existantes trop gobbles. Voici mon explication en clair:

STA: Si un thread crée un objet COM défini sur STA (lorsque vous appelez CoCreateXXX, vous pouvez transmettre un indicateur définissant l'objet COM en mode STA), seul ce thread peut accéder à cet objet COM (c'est ce que STA signifie - Appartement à thread unique), L’autre thread qui tente d’appeler des méthodes sur cet objet COM est sous le capot, transformé silencieusement en remise de messages au thread qui crée (possède) l’objet COM. Cela ressemble beaucoup au fait que seul le thread qui a créé un contrôle d'interface utilisateur peut y accéder directement. Et ce mécanisme est destiné à éviter les opérations compliquées de verrouillage / déverrouillage.

MTA: Si un thread crée un objet COM défini sur MTA, chaque thread peut appeler directement des méthodes dessus.

C'est à peu près l'essentiel. Bien que, techniquement, je n’ai pas mentionné certains détails, comme dans le paragraphe "STA", le fil du créateur doit être lui-même STA. Mais c’est à peu près tout ce que vous devez savoir pour comprendre STA / MTA / NA.

STA (Single Threaded Apartment) est essentiellement le concept selon lequel un seul thread interagit avec votre code à la fois. Les appels dans votre appartement sont marshalés via des messages Windows (en utilisant une fenêtre non visible). Cela permet de mettre les appels en file d'attente et d'attendre la fin des opérations.

MTA (Multi Threaded Apartment) est le lieu où de nombreux threads peuvent tous fonctionner en même temps et il incombe à vous en tant que développeur de gérer la sécurité des threads.

Il y a beaucoup plus à apprendre sur les modèles de thread dans COM, mais si vous rencontrez des difficultés pour comprendre ce qu'ils sont, je dirais que comprendre ce qu'est la STA et son fonctionnement serait le meilleur point de départ, car la plupart des objets COM sont STA & # 8217; s.

Threads de l'appartement, si un thread habite dans le même appartement que l'objet qu'il utilise, il s'agit d'un thread de l'appartement. Je pense qu'il ne s'agit que d'un concept COM, car il ne s'agit que d'une manière de parler des objets et des threads avec lesquels ils interagissent & # 8230;

Chaque EXE qui héberge des contrôles COM ou OLE définit son état d'appartement. L'état d'appartement est par défaut STA (et pour la plupart des programmes, STA devrait être utilisé).

STA : tous les contrôles OLE doivent nécessairement habiter dans une STA. STA signifie que votre objet COM doit toujours être manipulé sur le thread d'interface utilisateur et ne peut pas être transmis à d'autres threads (un peu comme n'importe quel élément d'interface utilisateur de MFC). Cependant, votre programme peut toujours avoir plusieurs threads.

MTA : vous pouvez manipuler l'objet COM sur n'importe quel thread de votre programme.

D'après ce que j'ai compris, "Appartement" est utilisé pour protéger les objets COM des problèmes de multi-threading.

Si un objet COM n'est pas thread-safe, il doit le déclarer en tant qu'objet STA. Alors seul le fil qui le crée peut y accéder. Le thread de création devrait se déclarer comme un thread STA. Sous le capot, le thread stocke les informations STA dans son TLS (Thread Local Storage). Nous appelons ce comportement le fait que le thread entre dans un appartement STA. Lorsque d'autres threads veulent accéder à cet objet COM, il doit organiser l'accès au thread de création. Fondamentalement, le fil de création utilise le mécanisme de messages pour traiter les appels entrants.

Si un objet COM est thread-safe, il doit le déclarer en tant qu'objet MTA. L’objet MTA est accessible par plusieurs threads.

Le code qui appelle les DLL d'objet COM (par exemple, pour lire des fichiers de données propriétaires) peut fonctionner correctement dans une interface utilisateur, mais se suspendre mystérieusement à un service. La raison en est que, à partir de .Net 2.0, les interfaces utilisateur supposent STA (thread-safe) tandis que les services assument MTA ((auparavant, les services supposaient STA). Le fait de créer un thread STA pour chaque appel COM dans un service peut ajouter un surcoût important.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top