Pourriez-vous expliquer STA et MTA?

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

En outre, quels sont les fils d’appartement et ne concernent-ils que COM? Si oui, pourquoi?

Le modèle de thread COM est appelé un modèle “appartement”, où le contexte d’exécution des objects COM initialisés est associé à un seul thread (Single Thread Apartment) ou à de nombreux threads (Multi Thread Apartment). Dans ce modèle, un object COM, une fois initialisé dans un appartement, fait partie de cet appartement pour la durée de son exécution.

Le modèle STA est utilisé pour les objects 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. Donc, si un autre thread doit interagir avec l’object (par exemple, en appuyant sur un bouton dans un formulaire), le message est placé sur le thread STA. Le système de pompage des messages Windows Forms en est un exemple.

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

Tout dépend de la manière dont les appels aux objects sont traités et de la protection dont ils ont besoin. Les objects COM peuvent demander au moteur d’exécution de les protéger contre l’appel de plusieurs threads en même temps. ceux qui ne peuvent pas être appelés simultanément à partir de différents threads, ils doivent donc protéger leurs propres données.

En outre, le moteur d’exécution doit également empêcher un appel d’object COM de bloquer l’interface utilisateur si un appel est effectué à partir d’un thread d’interface utilisateur.

Un appartement est un lieu où les objects vivent, et ils contiennent un ou plusieurs fils. L’appartement définit ce qui se passe lorsque les appels sont faits. Les appels aux objects dans un appartement seront reçus et traités sur n’importe quel thread dans cet appartement, à ceci près qu’un appel par un thread déjà dans le bon appartement est traité par lui-même (c’est-à-dire un appel direct à l’object).

Les threads peuvent être dans un appartement à thread unique (auquel cas ils sont le seul thread dans cet appartement) ou dans un appartement à threads multiples. Ils spécifient lequel lorsque le thread initialise COM pour ce thread.

Le STA est principalement pour 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 masquée; lorsqu’il effectue un appel sortant, il lance une boucle de message modal pour empêcher le traitement d’autres messages de fenêtre. Vous pouvez spécifier un filtre de messages à appeler pour 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 threads effectuant des appels sortants se bloquent simplement.

Pour plus de simplicité, nous considérons uniquement les objects implémentés dans les DLL, qui annoncent dans le registre ce qu’ils prennent en charge, en définissant la valeur ThreadingModel pour la clé de leur classe. Il y a quatre options:

  • Fil principal (valeur ThreadingModel non présente). L’object est créé sur le thread d’interface utilisateur principal de l’hôte et tous les appels sont regroupés dans ce thread. La classe factory ne sera appelée que sur ce thread.
  • Apartment 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’object s’exécutera sur ce thread, sinon il sera créé dans le STA principal – si aucun STA principal n’existe, un thread STA sera créé pour lui. (Cela signifie que les threads MTA qui créent des objects d’appartement vont rassembler tous les appels vers un thread différent.) La fabrique de classes peut être appelée simultanément par plusieurs threads STA pour protéger ses données internes.
  • Free 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 encore que les appels du thread STA seront regroupés. C’est parce qu’un object Free est généralement écrit avec l’espoir qu’il peut bloquer.
  • Both Ces classes sont flexibles et se chargent dans l’appartement de leur choix. Ils doivent cependant ê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 seraient chargés dans le MTA, mais ne devraient pas être bloqués au cas où ils seraient chargés dans un STA.

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

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

STA: Si un thread crée un object COM défini sur STA (lorsque vous appelez CoCreateXXX, vous pouvez passer un indicateur qui définit l’object COM sur le mode STA), seul ce thread peut accéder à cet object COM (c’est ce que signifie STA – Single Threaded Apartment) ), un autre thread essayant d’appeler des méthodes sur cet object COM est sous le capot silencieusement transformé en livraison de messages au thread qui crée l’object COM (propriétaire). 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é à empêcher les opérations compliquées de locking / délocking.

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

C’est à peu près l’essentiel. Bien que techniquement il y ait des détails que je n’ai pas mentionnés, comme dans le paragraphe ‘STA’, le thread créateur doit lui-même être 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 interagira avec votre code à la fois. Les appels dans votre appartement sont rassemblés via des messages Windows (en utilisant une fenêtre non visible). Cela permet de mettre les appels en attente et d’attendre la fin des opérations.

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

Il y a beaucoup à apprendre sur les modèles de threading dans COM, mais si vous avez du mal à comprendre ce qu’ils sont, je dirais que comprendre le STA et son fonctionnement serait le meilleur sharepoint départ car la plupart des objects COM sont des STA.

Appartement Threads, si un thread réside dans le même appartement que l’object qu’il utilise, il s’agit d’un thread d’appartement. Je pense que ce n’est qu’un concept COM, car ce n’est qu’une façon de parler des objects et des threads avec lesquels ils interagissent…

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

STA – Tous les contrôles OLE doivent nécessairement se trouver dans un STA. STA signifie que votre object 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 dans MFC). Cependant, votre programme peut encore contenir de nombreux threads.

MTA – Vous pouvez manipuler l’object COM sur n’importe quel thread de votre programme.

Comme je le comprends, le «appartement» est utilisé pour protéger les objects COM contre les problèmes multi-threading.

Si un object COM n’est pas compatible avec les threads, il doit le déclarer en tant qu’object STA. Ensuite, seul le thread qui le crée peut y accéder. Le thread de création doit 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 que le thread entre dans un appartement STA. Lorsque d’autres threads veulent accéder à cet object COM, il doit marshérer l’access au thread de création. Fondamentalement, le thread de création utilise un mécanisme de messages pour traiter les appels entrants.

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

Le code qui appelle les DLL d’object COM (par exemple, pour lire des fichiers de données propriétaires) peut fonctionner correctement dans une interface utilisateur, mais se bloquer mystérieusement dans un service. La raison en est que, à partir de .Net 2.0, les interfaces utilisateur prennent en charge STA (thread-safe) alors que les services supposent MTA (avant, les services supposaient STA).