Pouvez-vous expliquer STA et MTA?

tout dépend de la façon dont les appels aux objets sont traités et de la protection dont ils ont besoin. Les objets COM peuvent demander à l'exécution de les protéger contre le fait d'être appelés par plusieurs threads en même temps; ceux qui ne le sont pas peuvent potentiellement être appelés simultanément à partir de différents threads, donc ils doivent protéger leurs propres données.

En outre, il est également nécessaire pour l'exécution d'empêcher un objet COM appel de blocage de l'interface utilisateur, si un appel est effectué à partir d'un utilisateur thread d'interface.

An appartement est un endroit pour les objets à vivre, et ils contiennent un ou plusieurs fils. L'appartement définit ce qui arrive quand les appels sont effectués. Les appels à des objets dans un appartement seront reçus et traités sur n'importe quel fil dans cet appartement, à l'exception qu'un appel par un fil déjà dans le bon appartement est traité par lui-même (c.-à-d. un appel direct à l'objet).

fils peuvent être soit dans un Appartement à filetage simple (dans ce cas, ils sont le seul filetage dans cet appartement) ou dans un appartement à filetage multiple. Ils spécifient quand 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 sit reçoit des notifications d'appels à traiter en recevant un message de fenêtre vers une fenêtre cachée; lorsqu'il fait un appel sortant, il démarre une boucle de message modale pour empêcher les autres messages de fenêtres en cours de traitement. Vous pouvez spécifier un filtre de message à appeler, afin que votre application puisse répondre à d'autres messages.

par contraste, tous les fils MTA partagent un seul MTA pour le processus. COM vous pouvez démarrer un nouveau thread pour gérer un appel entrant si aucun thread n'est disponible, jusqu'à une limite du pool. Les Threads faisant des appels sortants bloquent simplement.

par souci de simplicité, nous ne considérerons que les objets implémentés dans les DLLs, qui font de la publicité dans les enregistrez ce qu'ils supportent, en définissant la valeur ThreadingModel pour la clé de leur classe. Il y a quatre options:

• thread Principal ( ThreadingModel la valeur n'est pas présent). L'objet est créé sur le fil UI principal de l'hôte, et tous les appels sont placés sur ce fil. L'usine de la classe ne sera appelée que sur ce fil.
• Apartment . Cela indique que la classe peut s'exécuter sur n'importe quel thread mono-mode. Si le fil qui la crée est un thread STA, l'objet fonctionnera 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 fils MTA qui créent des objets D'Appartement vont regrouper tous les appels à un fil différent.) La classe factory peut être appelée simultanément par plusieurs threads STA, de sorte qu'elle doit protéger ses données internes contre cela.
• Free . Cela indique une classe conçue pour fonctionner dans la MTA. Il sera toujours chargez dans le MTA, même si créé par un thread STA, ce qui signifie que les appels du thread STA seront marshalled. C'est parce qu'un Free l'objet est généralement écrit avec l'espoir qu'il peut bloquer.
• Both . Ces classes sont flexibles et chargent dans n'importe quel appartement d'où ils sont créés. Ils doivent être écrits pour correspondre aux deux séries d'exigences, cependant: ils doivent protéger leur état interne contre les appels concurrents, au cas où ils sont chargés dans le MTA, mais ne doit pas bloquer, au cas où ils sont chargés dans un STA.

du Framework .NET, utilisez simplement [STAThread] sur n'importe quel fil qui crée L'UI. Les threads Worker devraient utiliser le MTA, à moins qu'ils n'utilisent des composants COM marqués Apartment , dans ce cas, utilisez le STA pour éviter les problèmes de marshalling overhead et d'évolutivité si le même composant est appelé à partir de plusieurs threads (car chaque thread devra attendre le composant à son tour). C'est beaucoup plus facile tout autour si vous utilisez un objet COM séparé par thread, si le composant est dans le STA ou MTA.

je trouve les explications existantes trop simplistes. Voici mon explication en anglais:

STA: Si un thread crée un objet COM qui est défini à STA (lors de L'appel CoCreateXXX vous pouvez passer un drapeau qui définit L'objet COM en mode STA), alors seul ce thread peut accéder à cet objet COM (C'est ce que STA signifie - Appartement fileté simple), d'autres thread essayant d'appeler des méthodes sur cet objet COM est sous le capot silencieusement transformé en livrer des messages à la fil qui crée (possède) L'objet COM. Cela ressemble beaucoup au fait que seul le thread qui a créé un contrôle de L'interface utilisateur peut y accéder directement. Et ce mécanisme est destiné à empêcher les opérations compliquées de verrouillage/déverrouillage.

MTA: Si un thread crée un objet COM qui est défini à MTA, alors à peu près chaque thread peut directement appeler des méthodes sur lui.

C'est à peu près l'essentiel. Bien que techniquement il y ait certains détails que je n'ai pas mentionnés, tels que dans le paragraphe "STA", le fil 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 qu'un seul thread interagira avec votre code à la fois. Les appels dans votre appartement sont acheminés via des messages windows (en utilisant une fenêtre non visible). Cela permet aux appels d'être mis en file d'attente et d'attendre que les opérations soient terminées.

MTA (Multi Threaded Apartment) est où de nombreux threads peuvent fonctionner en même temps et la charge est sur vous en tant que développeur de gérer la sécurité du thread.

il y a beaucoup plus à apprendre sur les modèles de threading dans COM, mais si vous avez des difficultés à comprendre ce qu'ils sont alors je dirais que comprendre ce QU'est le STA et comment il fonctionne serait le meilleur endroit de départ parce que la plupart des objets COM sont STA.

Appartement Fils, si un thread vit dans le même appartement que l'objet qu'il utilise, alors c'est un appartement de fil. Je pense que ce n'est qu'un concept de COM parce que ce n'est qu'une façon de parler de la objets et fils avec lesquels ils interagissent ...

chaque EXE qui héberge COM ou OLE controls 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 - toutes les commandes LOE par nécessité doivent vivre dans un STA. STA signifie que votre COM-object doit toujours être manipulé sur le thread de L'interface utilisateur et ne peut pas être passé à d'autres threads (un peu comme n'importe quel élément de L'interface utilisateur dans MFC). Cependant, votre programme peut encore avoir de nombreux fils.

MTA - vous pouvez manipuler L'objet COM sur n'importe quel fil dans votre programme.

d'après ce que j'ai compris, "L'appartement" est utilisé pour protéger les objets COM contre les problèmes de multi-threading.

si un objet COM n'est pas thread-safe, il doit le déclarer comme un objet STA. Alors seulement le fil qui crée il peut accéder. Le fil de création doit se déclarer comme un fil STA. Sous la hotte, le thread stocke les informations STA dans son TLS(Thread Local Storage). Nous appelons ce comportement que le fil pénètre dans un appartement STA. Lorsque d'autres threads si vous voulez accéder à cet objet COM, il devrait canaliser l'accès au thread de création. Fondamentalement, le thread de création utilise un mécanisme de messages pour traiter les appels entrants.

si un objet COM est thread-safe, il doit le déclarer comme un objet MTA. L'objet MTA est accessible par multi-threads.

Code qui appelle COM object dlls (par exemple, pour lire des fichiers de données propriétaires), peut fonctionner très bien dans une interface utilisateur, mais accrocher mystérieusement d'un service. La raison en est que, à partir de .Net 2.0, les interfaces utilisateurs assument STA (thread-safe) tandis que les services assument MTA ((avant cela, les services supposaient STA). Avoir à créer un fil STA pour chaque appel COM dans un service peut ajouter un dépassement significatif.