INFO: Beschreibung und Funktionsweise von OLE Threadingmodelle

Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.

Den englischen Originalartikel können Sie über folgenden Link abrufen: 150777
Zusammenfassung
COM-Objekte können in mehreren Threads eines Prozesses verwendet werden. Die Begriffe "Single-threaded Apartment" (STA) und "Multithreaded Apartment" (MTA) verwendet umeine Konzept zur Beschreibung der Beziehung Betweenobjects und Threads Parallelität Beziehungen zwischen Objekten, die Methode ruft, Meansby an ein Objekt und die Regeln für Passinginterface Zeiger Threads geliefert werden. Komponenten und deren Clients Choosebetween unterstützt die folgenden zwei Apartment Modelle derzeit von COM:

  1. Singlethread-Apartment-Modell (STA): Ein oder mehrere Threads in einem Prozess verwenden COM und COM-Objekt-Aufrufe werden durch COM synchronisiert. Interfaces werden zwischen Threads gemarshallt. Ein degenerierter Fall des Single-Thread-Apartment-Modells, in dem nur ein Thread in einem bestimmten Prozess COM verwendet, heißt das Single-Threading-Modell. Frühere Microsoft Informationen und Dokumentationen bezeichnen manchmal das STA-Modell einfach als das "Apartmentmodell"
  2. Multi-threaded Apartment-Modell (MTA): ein oder mehrere Threads verwenden COM und COM-Objekte mit dem MTA verbundenen Aufrufe werden direkt von allen Threads MTA ohne jede Sortenname Systemcode zwischen Aufrufer und Objekt zugeordnet. Da mehrere gleichzeitige Clients Objekte gleichzeitig (gleichzeitig auf Mehrprozessorsystemen) aufrufen können, müssen den internen Zustand Objekte selbst synchronisiert werden. Schnittstellen werden nicht zwischen Threads gemarshallt. Vorherige Microsoft Informationen und Dokumentation hat manchmal dieses Modell als die "Freethreadmodell."
  3. Das STA-Modell und die MTA-Modell können im gleichen Prozess verwendet werden. Dies wird manchmal als "gemischter Entwicklungsmodelle" Prozess bezeichnet.
Der MTA wird unter NT 4.0 eingeführt und steht in Windows 95 mit DCOM95. Das STA-Modell ist in Windows NT 3.51 und Windows 95 und NT 4.0and Windows 95 mit DCOM95 vorhanden.
Weitere Informationen

Übersicht

Threadingmodelle in COM bereitstellen Mechanismus für Komponenten, zweiverschiedene threading Architekturen zusammenarbeiten. Sie auch Providesynchronization Dienste für die Komponenten, die sie benötigen. Beispielsweise Aparticular-Objekt kann so ausgelegt sein aufgerufen werden durch einen einzelnen Thread Andmay nicht synchronisiert gleichzeitige Aufrufe von Clients. Wenn solche einem Objekt Iscalled gleichzeitig von mehreren Threads, Abstürze oder Fehler verursacht. COMprovides der Mechanismen für den Umgang mit diesem Interoperabilität des Threadingarchitectures.

Thread-bewusst Komponenten benötigen häufig Synchronisierungsdienste. Beispielsweise Komponenten mit graphical User Interface (GUI), solche AsOLE-ActiveX-Steuerelemente in-Place aktiv eingebetteten und ActiveX-Dokumente erfordern Synchronisierung und Serialisierung von COM-Aufrufe und messages.COM mit Fenster erbringt diese Synchronisierung und diese Komponenten Bewritten ohne komplexe Synchronisierungscode.

"Apartment" hat mehrere Aspekte miteinander. Es ist ein Logicalconstruct denken Parallelität wie Aset von COM-Objekten wie Threads beziehen. Zweitens ist es, ein Satz von Regeln Programmierer Toreceive Parallelitätsverhalten einhalten muss COM-Umgebung erwarten. Schließlich wird vom System bereitgestellten Code, mit dem Programmierer Thread Concurrencywith gegenüber COM-Objekte verwalten kann.

Der Begriff "Apartment" aus Metapher, in der ein Prozess Conceivedas völlig eigenständige Einheit ist, wie Stockwerken Satz verwandter unterteilt eine "Gebäude", aber unterschiedliche "Locales" aufgerufen "Apartments." Eine privatistnatürlich einer logischen "Container", der eine Zuordnung zwischen Objekten und in einigen Fällen Threads erstellt. Threads sind Apartments, auch Single Thread Apartment in das STA-Modell logisch zugeordnet. Objekte sind nicht Apartments, obwohl jedes Objekt nur ein Apartment umkomplizierte zugeordnet ist. Aber mehr Logicalconstruct sind. Ihre Regeln Beschreiben des Verhaltens von com-System. Therules Modelle Apartment nicht eingehalten werden, werden COM-Objekte Notfunction ordnungsgemäß.

Weitere Informationen

Singlethread-Apartment (STA) ist ein Satz von COM-Objekten Aparticular Thread zugeordnet. Diese Objekte sind Apartment von Beingcreated vom Thread oder, genauer gesagt, wird zunächst ausgesetzt COMsystem (normalerweise durch Marshallen) auf dem Thread zugeordnet. EINE Station Hotel gilt, in dem ein Objekt oder einen Proxy "befindet." Wenn das Objekt oder der Proxy zu einem anderen Apartment (im selben oder in einem anderen Prozess) zugegriffen benötigt, muss Itsinterface Zeiger, Wohnung, einen neuen Proxy wird gemarshallt werden. Das Apartmentmodell gefolgt, keine direkte Systemaufrufevon sind dürfen andere Threads in diesem Prozess für dieses Objekt; Thatwould gegen die Regel, dass alle Objekte in einem bestimmten Apartment Single-Thread ausgeführt. Die Regel vorhanden ist, da die meisten Code ausgeführt in einem STA-Willfail Funktion ordnungsgemäß auf zusätzliche Threads ausgeführt.

Der Thread eine STA CoInitialize OrCoInitializeEx (NULL, COINIT_APARTMENTTHREADED) muss aufrufen und Anddispatch Fensternachrichten für die zugehörigen Objekte Incomingcalls empfangen abrufen muss. COM löst und Aufrufe von Objekten in einem STA Usingwindow Nachrichten synchronisiert, wie in diesem Artikel beschrieben.

"main STA" ist der Thread, der innerhalb eines bestimmten Prozesses zunächst CoInitialize orCoInitializeEx(NULL,COINIT_APARTMENTTHREADED) Ruft. Die wichtigste Station eines Prozesses muss aktiv bleiben, bis alle COM-Completedbecause arbeitet einige Objekte im in-Proc main STA Asdescribed später in diesem Artikel immer geladen werden.

Windows NT 4.0 und DCOM95 stellen eine neue Art von Apartment aufgerufen Themulti Singlethreaded Apartment (MTA). Ein MTA ist ein Satz von COM-Objekten Associatedwith mehrere Threads im Prozess ein Thread Anyobject Implementierung ohne Sortenname Systemcode direkt aufrufen kann. Schnittstellenzeiger auf jedes Objekt im MTA werden unter Threadsassociated mit dem MTA übergeben, ohne gemarshallt werden. Alle Threads in Prozessvariable, die CoInitializeEx (NULL, COINIT_MULTITHREADED) aufrufen werden Associatedwith der MTA. Im Gegensatz zur oben beschriebenen STA führen Threads in einem MTA NICHTFÜR zum Abrufen und senden Fensternachrichten zugeordneten Objekte Toreceive eingehende Anrufe. COM wird Aufrufe von Objekten in AnMTA synchronisiert. Objekte in einem MTA müssen ihren internen Status von Korruption Bythe Interaktion von mehreren Threads gleichzeitig schützen und sie können über den Inhalt der übrigen lokalen Thread-Speicher-Constantbetween Anyassumptions anderen Methodenaufrufen.

Ein Prozess kann eine beliebige Anzahl von Stationen, aber höchstens haben ein MTA. TheMTA besteht aus einem oder mehreren Threads. Stationen haben einen Thread. Ein Threadbelongs höchstens eine Wohnung. Objekte gehören und nur Oneapartment. Schnittstellenzeigern sollte immer zwischen Apartments gemarshallt werden (obwohl aus Marshalling statt Aproxy einen direkten Zeiger sein kann). Finden Sie Informationen unter CoCreateFreeThreadedMarshaler.

Ein Prozess wählt einen Threadingmodelle von COM bereitgestellt Ein STA-Modelprocess eine oder mehrere Stationen und keinen MTA. Ein MTA Modell Processhas MTA mit einem oder mehreren threads und verfügt nicht über alle Stationen. Ein gemischter Entwicklungsmodelle Prozess besitzt ein MTA und eine beliebige Anzahl von Stationen.

Singlethread-Apartment-Modell

Der Thread eine STA müssen Sie CoInitialize oder CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) aufrufen und abrufen muss und Dispatch Fenster Messagesbecause com-Fensternachrichten synchronisieren und dispatch-Aufrufe Deliveryof auf ein Objekt in diesem Modell verwendet. Siehe Abschnitt Verweise Weitere Informationen.

Server, STA-Modell unterstützt:

In das STA-Modell werden Aufrufe an ein Objekt von COM der Samemanner synchronisiert als Fensternachrichten an ein synchronisiert werden. Aredelivered Fenster Nachrichten an den Thread, der das Objekt erstellt wird. Daher muss das Objekt Thread Get-PeekMessage AndDispatchMessage um Anrufe aufrufen. COM erstellt ein ausgeblendetes Fenster Associatedwith jeder Station. Ein Aufruf an ein Objekt außerhalb der Station ist übertragenen ByCOM Laufzeit der Thread des Objekts über eine Fensternachricht Thishidden Fenster gebucht. Wenn das Objekt STA Retrievesand zugeordnet die Nachricht sendet, erhält die Fensterprozedur für ausgeblendete Fenster auch durch COM implementiert. Die Fensterprozedur TheCOM Runtime dient die Station zugeordnet ist die COMruntime auf beiden Seiten der Aufruf aus COM gehören Thread der STA'sthread "verknüpfen". Com-Laufzeit (inzwischen in dem STA-Thread) Ruft "" über aCOM angegebenen Stub in die entsprechende Schnittstellenmethode des Objekts. Ausführungspfad vom Methodenaufruf zurückgegeben "oben" Aufruf kehrt den Aufrufs der Stub und COM-Runtime die Controlback com-Runtime Thread über eine Meldung, die dann Returnsthrough der COM-Kanal auf den ursprünglichen Aufrufer übergibt;

Wenn mehrere Clients STA-Objekt aufrufen, werden die Aufrufe Automaticallyqueued in der Warteschlange mit der Übertragung der Kontrollmechanismus in die Station verwendet Das Objekt erhält einen Anruf bei jedem der Station Anddispatches Nachrichten abgerufen. Da Aufrufe von COM in Thismanner synchronisiert werden, und die Aufrufe immer für die einzelnen Threadassociated mit dem Objekt STA übermittelt werden, müssen das Objekt Schnittstelle Implementierungen Synchronisierung.

Hinweis: Objekts erneut eingegeben werden, wenn eine Methodimplementation Schnittstelle abruft und Nachrichten überträgt während der Verarbeitung einer Methodcall ist verursacht an das Objekt durch den gleichen gemeinsamen Station übermittelt werden wie in der in diesem Fall ein STA-Objekt macht eine out-going(cross-apartment/cross-process) anrufen über COM Dies ist identisch mit Themanner, in dem eine Fensterprozedur erneut eingegeben werden kann, wenn beim Verarbeiten einer Nachricht Anddispatches Nachrichten abgerufen. COM nicht Re-entrance auf dem gleichen Thread jedoch verhindert, dass gleichzeitige Ausführung. Italso kann mit dem COM-bezogene Reentranz verwaltet werden kann. Vgl. Abschnitt unter Weitere Informationen. Das Objekt ist nicht neu eingegebene Methode Implementierungen nicht aus der Wohnung Orotherwise aufrufen abrufen und Senden von Nachrichten.

Client-Aufgaben in das STA-Modell:

Client-Code in einem Prozess oder Thread, mit STA-Modell Mustmarshal Schnittstellen eines Objekts zwischen Apartments durch UsingCoMarshalInterThreadInterfaceInStream und CoGetInterfaceAndReleaseStream.For Beispiel wenn Apartment 1 in der Client einen Schnittstellenzeiger, AndApartment 2 benötigen sie, Apartment 1 Interfaceusing CoMarshalInterThreadInterfaceInStream marshallen müssen ausgeführt. Das Stream-Objekt zurückgegebenen Bythis Funktion threadsicher und der Schnittstellenzeiger gespeicherten Ina DMA Variable zugegriffen Apartment 2. Apartment 2 Passthis Stream Schnittstelle CoGetInterfaceAndReleaseStream unmarshal dieses auf das zugrunde liegende Objekt und einen Zeiger auf einen Proxythrough zugreifen können muss das Objekt.

Main Apartment eines bestimmten Prozesses sollte aktiv bleiben, bis der Clienthas alle COM Arbeit abgeschlossen, da einige Objekte prozessintern in Apartmentzustand Apartment geladen werden. (Weitere Informationen wird nachfolgend beschrieben).

Multi-threaded Apartment-Modell

Ein MTA ist die Auflistung der Objekte erstellt oder die Threadsin vom Prozess, der CoInitializeEx (NULL, COINIT_MULTITHREADED) aufgerufen.

Hinweis: die aktuelle Implementierung von COM können ein Thread, das Notexplicitly Initialisierung COM zu einem Teil des MTA. Ein Thread, die Notinitialize COM ist Bestandteil des MTA nur beginnt mit COM nach mindestens einen Thread im Prozess zuvor CalledCoInitializeEx (NULL, COINIT_MULTITHREADED). (Es ist auch möglich, dass COMitself den MTA initialisiert haben kann, wenn keine Clientthread Explicitlydone so, z. B. ein Thread eine STA-CallsCoGetClassObject/CoCreateInstance [Ex] zugeordnet, eine CLSID markiert ist "ThreadingModel = frei" und COM erstellt implizit einen MTA in die Theclass Objekt geladen.) Informationen Sie zu Threads Modelinteroperability unten.

Dies ist jedoch eine Konfiguration, die solche Verstöße Asaccess unter Umständen Probleme verursachen können. Daher ist es Stronglyrecommended, dass jeder Thread, die COM-Arbeit COM Bycalling CoInitializeEx initialisieren und dann nach Abschluss der COM-Arbeit, CallCoUninitialize. Die Kosten für "unnötig" einen MTA-Initialisierung ist minimal.

MTA-Threads müssen nicht abrufen und Nachrichten senden, da COM Fensternachrichten in diesem Modell verwenden, um Aufrufe an ein Objekt übermitteln.

Server, die der MTA unterstützt:

Im Modell MTA Aufrufe eines-Objekts werden nicht synchronisiert, indem COM-Multipleclients können gleichzeitig ein Objekt, das dieses Modell Ondifferent Threads unterstützt und das Objekt Synchronisierung Synchronisation Itsinterface-Methode Implementierung Objekte so Asevents, Mutexe, Semaphoren usw. bereitstellen muss. MTA-Objekte erhalten gleichzeitige Systemaufrufevon mehrere Out-of-Process-Clients über einen Pool von Threadsbelonging für das Objekt Prozess COM erstellt. MTA-Objekte erhalten gleichzeitige Systemaufrufevon mehrere in-Process-Clients in mehreren Threads TheMTA zugeordnet.

Client-Aufgaben im MTA-Modell:

Client-Code in einem Prozess oder Thread, mit dem MTA Modell verfügt ausgeführt haben Marshallen Schnittstellenzeigern eines Objekts zwischen sich selbst und andere MTA-Threads. Stattdessen können ein MTA-Thread eine Schnittstelle Pointerobtained von einem anderen MTA-Thread als direkte Speicherzeiger. Wenn ein Clientthread ein Out-of-Process-Objekt aufruft, wird bis der Callhas abgeschlossen. Aufrufe kommen möglicherweise auf Objekte mit dem MTA Whileall Anwendung erstellte Threads mit dem MTA verbunden sind blockiert ausgehenden Anrufe. In diesem Fall und generell werden eingehende Anrufe von COM-Runtime bereitgestellten Onthreads geliefert. Message Filter (IMessageFilter)-Anweisungen für MTA-Modell verfügbar.

Gemischte Threading-Modell

Ein Prozess, der gemischten threading-Modell unterstützt werden weitere Stationen ein MTA und Oneor verwenden. Schnittstellenzeigern gemarshallt werden müssen, alle Apartmentsbut ohne Marshalling innerhalb der MTA verwendet werden kann. Aufrufe von Objekten in AnSTA werden von COM nur ein Thread ausgeführt, ruft Toobjects im MTA nicht synchronisiert. Ruft jedoch von einer Station, ein MTA-Normallygo System-Code und Switch aus dem STA-Thread auf eine MTAthread vor Auslieferung auf das Objekt.

Hinweis: finden Sie in der SDK-Dokumentation für CoCreateFreeThreadedMarshaler() und Thediscussion, unten API für Informationen über direkte Pointerscan verwendet werden und wie ein STA-Thread direkt in ein Firstassociated Objekt, mit dem MTA und umgekehrt aus mehreren Apartments aufrufen kann.

Das Threading-Modell auswählen

Eine Komponente können das STA-Modell, MTA Modell oder verschiedenartiger mithilfe der gemischten-Threadingmodell unterstützt. Beispielsweise können Anobject, die umfangreiche e/a MTA Maximumresponse für Clients bereitstellen Downloadfunktion Schnittstellenaufrufe während ich zu unterstützen / Olatency. Ein Objekt, mit dem Benutzer Almostalways interagiert, möchte auch unterstützen STA COM-Anrufe mit ItsGUI synchronisieren. Unterstützt das STA-Modell ist einfacher, da COM-Providessynchronization. MTA-Modell unterstützt ist schwieriger, weil Theobject Synchronisierung implementieren muss auf Clients, Betterbecause Synchronisation für kleinere Abschnitte des Codes, sondern Thanfor Schnittstellenaufruf von COM verwendet wird

Das STA-Modell wird auch von Microsoft Transaction Server (MTS Previouslycode namens "Viper") und DLL-basierte Objekte können TheMTS Umgebung planen sollten daher das STA-Modell verwenden. Objekte für die MTAmodel werden normalerweise in einer MTS-Umgebung funktionieren. Allerdings werden sie runless effizient da sie unnötige Threadsynchronization primitiven verwendet.

Unterstützt-threading Model prozessinternen Server markieren

Ein Thread verwendet das MTA ruft CoInitializeEx(NULL,COINIT_MULTITHREADED) oder COM ohne Initialisierung verwendet. Ein Thread verwenden bewirkt, dassdie STA-Modell CoInitialize oder CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) aufgerufen.

CoInitialize APIs bieten Apartment Steuerelement für Clientcode und Forobjects, die in enthalten sind. EXE-Dateien, da die COM-Laufzeit Start Codecan COM in der gewünschten Weise initialisieren.

Ein prozessinterner COM (DLL-basiert) Server jedoch nicht CallCoInitialize-CoInitializeEx da APIs von willigen Server DLL aufgerufen wurden wird geladen. Daher muss DLL-Server Theregistry verwenden, COM das Threadingmodell informiert unterstützt, damit COM-Canensure, so funktioniert das kompatibel ist. Anamed Wert der wichtigsten CalledThreadingModel für die Komponente CLSID\InprocServer32 ist für diesen Zweck verwendet:

  • ThreadingModel-Wert nicht vorhanden: Single-threading-Modell unterstützt.
  • ThreadingModel = Apartment: unterstützt STA Modell.
  • ThreadingModel = beides: unterstützt STA und MTA-Modell.
  • ThreadingModel = frei: nur MTA unterstützt.
Hinweis: ThreadingModel ist ein benannter Wert, keinen Unterschlüssel InprocServer32 Asincorrectly in einigen früheren Versionen der Win32-Dokumentation beschrieben.

Threadingmodelle von prozessinternen Servern werden später in diesem Artikel erläutert. Ifan prozessinterner Server bietet viele Objekttypen (jeder mit eigenen UniqueCLSID), jeder Typ kann einen anderen ThreadingModel-Wert verfügen. In anderen Worten ist das Threadingmodell pro CLSID nicht pro Code Paket/DLL. Jedoch die API Einstiegspunkte "bootstrap" und alle Procservers Abfragen erforderlich (DLLGetClassObject(), DLLCanUnloadNow()) Forany threadsicher prozessinternen Server, mehrere Threads unterstützt, werden müssen (d. h. eine ThreadingModelvalue Apartment, oder frei).

Wie bereits erwähnt, Out-of-Process-Servern nicht selbst dazu ThreadingModel-Wert markieren. Stattdessen verwenden sie CoInitialize oder CoInitializeEx.DLL-basierten Servern, die Out-of-Process-mithilfe der Funktionen "Ersatz" von COM (z. B. das systemeigene-Ersatzzeichen DLLHOST. ausführen (EXE) einfach Regeln für DLL-basierte Server; Es gibt in diesem Fall keine Specialconsiderations.

Wenn Client und Objekt unterschiedliche Threadingmodelle verwenden

Interaktion zwischen einem Client und einem Out-of-Process-Objekt ist einfach, obwohl unterschiedliche Threadingmodelle verwendet werden, da das Objekt clientund in verschiedenen Prozessen und COM beteiligt Systemaufrufevon Client an das Objekt übergeben. Da COM Prüfrahmen zwischen clientund der Server ist bereitgestellt der Code für die Interoperation von den Threadingmodels. Wenn ein STA-Objekt mit MultipleSTA oder MTA Clients gleichzeitig aufgerufen wird, synchronisiert der COM Aufrufe durch Platzieren von Correspondingwindow Nachrichten in der Warteschlange des Servers an. Das Objekt STA Receivesone rufen Sie jedem abruft und überträgt Nachrichten. Alle Combinationsof-Threadmodell Interoperabilität dürfen und unterstützt Betweenclients und Out-of-Process-Objekte.

Interaktion zwischen einem Client und einem prozessinternen Objekt, Differentthreading Modelle ist komplizierter. Zwar der Server im in-Proc, COMmust stellen sich zwischen dem Client und dem Objekt in einigen Fällen. Beispielsweise kann ein prozessintern Objekt unterstützt das STA-Modell Calledconcurrently durch mehrere Threads für einen Client sein. COM kann nicht Clientthreads Schnittstelle des Objekts direkt zugreifen, da das Objekt Notdesigned für solche gleichzeitigen Zugriff ermöglichen. Stattdessen müssen COM, Callsare synchronisiert und von der Station mit "dem Objekt" zugeordnet. Trotz der Komplexität alle Kombinationen Ofthreading Modell Interoperabilität zwischen Clients und in Procobjects zulässig.

Threadingmodelle Out-of-Process-Server (EXE-basiert)

Folgende drei Kategorien von Out-of-Process-Server sind jeweils die können von jedem com-Client unabhängig von Thatclient verwendete Threadmodell verwendet:

  1. STA-Modellserver:

    Der Server funktioniert COM in eine oder mehrere Stationen. Eingehende Anrufe werden von COM synchronisiert und von den Thread der Station, in der das Objekt erstellt wurde, geliefert. Klassenfactory Methodenaufrufe werden durch die Station, die ClassFactory registriert zugeordnet übermittelt. Das Objekt und die Klassenfactory brauchen Synchronisierung implementieren. Die Implementierung muss jedoch auf mehrere Stationen verwendet globalen Variablen synchronisieren. Der Server muss CoMarshalInterThreadInterfaceInStream und CoGetInterfaceAndReleaseStreamto Marshallen Schnittstellenzeigern, möglicherweise von anderen Servern zwischen Stationen verwenden. Server kann optional IMessageFilter in jeder Station Aspekte steuern Lieferart Aufruf von COM implementieren. Ein degenerierter Fall ist der Single-threading Modellserver, der in einem STA COM funktioniert
  2. Modell-MTA-Server:

    Der Server funktioniert COM in einem oder mehreren Threads, die der MTA gehören. Anrufe werden nicht synchronisiert, indem COM COM erstellt einen Pool von Threads im Serverprozess und ein Aufrufs von einer dieser Threads gesendet wird. Threads müssen nicht zum Abrufen und Senden von Nachrichten. Die Factory-Objekt und Klasse muss Synchronisierung implementieren. Der Server muss nicht Schnittstellenzeiger zwischen Threads zu marshallen.
  3. Gemischtes Modellserver:

    Siehe Abschnitt in diesem Artikel "Mixed-threading-Modell" für Weitere Informationen.

Threadingmodelle Clients

Es gibt drei Kategorien von Clients:

  1. STA-Modell (Client):

    Der Client funktioniert COM Threads eine oder mehrere Stationen zugeordnet. Der Client muss Marshallen Schnittstellenzeigern zwischen Stationen CoMarshalInterThreadInterfaceInStream und CoGetInterfaceAndReleaseStream verwenden. Ein degenerierter Fall ist der Single-threading Model-Client, der in einem STA COM funktioniert Der Client-Thread hat eine Nachrichtenschleife bereitgestellte, wenn einen ausgehenden Anruf wird COM. Der Client können IMessageFilter Rückrufe und Verarbeitung von Fensternachrichten warten auf ausgehenden Aufrufe und andere Parallelitätsprobleme verwalten.
  2. MTA-Modell (Client):

    Der Client funktioniert COM in einem oder mehreren Threads, die der MTA gehören. Der Client muss nicht Schnittstellenzeiger zwischen Threads zu marshallen. Der Client kann keine IMessageFilter verwenden. Der Client Threads anhalten, wenn sie einen COM-Aufruf an eine Out-of-Process-Objekt und setzt bei den Aufrufs macht. Eingehende Anrufe werden auf COM erstellten und verwalteten Threads.
  3. Gemischtes Modell (Client):

    Siehe Abschnitt in diesem Artikel "Mixed-threading-Modell" für Weitere Informationen.

Threadingmodelle prozessinternen Server (DLL-basiert):

Es gibt vier Kategorien von prozessinternen Servern, die jeweils verwendeten Byany COM-Client unabhängig von diesem Client verwendete Threadmodell sein kann. Allerdings müssen prozessinternen Servern Marshallingcode eine benutzerdefinierte Schnittstelle (nicht-System definierte) bereitstellen, die sie implementieren, um Threadingmodel Interoperabilität unterstützt, da in der Regel, dass COM Marshallen Schnittstellen zwischen Clientapartments erfordert. Die vier Kategorien sind:

  1. Prozessinterne Server, single-threading ("main" STA) unterstützt-keine ThreadingModel-Wert:

    Ein Objekt von diesem Server erwartet die gleichen Client-Station zugreifen, erstellt wurde. Darüber hinaus erwartet der Server alle seine Einstiegspunkte DllGetClassObject DllCanUnloadNow und globalen Daten auf dem gleichen Thread (eine der wichtigsten Station zugeordnet). Vor der Einführung von Multi-threading in COM Servern sind in dieser Kategorie. Diese Server sollen nicht von mehreren Threads zugegriffen werden, damit COM alle Objekte, die vom Server in die wichtigsten Station des Prozesses erstellt und Aufrufe der Objekte werden durch die wichtigsten Station zugeordnet Andere Clientapartments Zugriff auf das Objekt über Proxys. Aufrufe von anderen Apartments Wechseln vom Proxy Stub in main STA (inter-Thread Marshallen) und anschließend das Objekt Durch dieses Marshalling kann COM-Aufrufe Objekts synchronisieren und Anrufe werden durch die Station, in der das Objekt erstellt wurde. Inter-Thread Marshallen ist langsam relativ direkt aufrufen, daher wird empfohlen, dass diese Server unterstützen mehrere Stationen (Kategorie 2) angepasst werden.
  2. Prozessinternen Server, das Singlethread-Apartment-Modell (mehrere Stationen) - unterstützt, markiert mit ThreadingModel = Apartment:

    Ein Objekt von diesem Server erwartet die gleichen Client-Station zugreifen, erstellt wurde. Daher ist ein Objekt von einem Singlethread-prozessinternen ähnelt. Jedoch können Objekte von diesem Server erstellt in mehrere Stationen des Prozesses, der Server die Einstiegspunkte DllGetClassObject DllCanUnloadNow und globalen Daten für Multithreading entwerfen muss. Wenn zwei Stationen eines Prozesses gleichzeitig zwei Instanzen des Objekts prozessintern erstellen, kann z. B. DllGetClassObject gleichzeitig von beiden Stationen aufgerufen. Ebenso muss DllCanUnloadNow geschrieben werden, sodass der Server geschützt von entladen werden, während noch Code auf dem Server ausgeführt wird.

    Stellt der Server nur eine Instanz die Klassenfactory, alle Objekte zu erstellen, muss die Implementierung der Klasse Factory Client mehrere Stationen zugegriffen wird auch für Multithread entwickelt. Wenn der Server eine neue Instanz der Klassenfactory jedes Mal DllGetClassObject aufgerufen wird erstellt, muss die Klassenfactory nicht threadsicher sein. Der Implementierer muss jedoch Zugriff auf globale Variablen synchronisieren.

    Die Klassenfactory erstellte COM-Objekte müssen nicht threadsicher sein. Zugriff auf globale Variablen muss jedoch von der Implementierung synchronisiert werden. Wenn durch einen Thread erstellt, wird das Objekt immer zugegriffen Thread und alle Aufrufe des Objekts durch Client com-Apartments synchronisiert werden, die anders als die Station, in der das Objekt erstellt wurde, Proxys Objekts zugreifen muss. Diese Proxys werden erstellt, wenn der Client die Schnittstelle zwischen der Apartments gemarshallt.

    Jeder Client, der ein STA-Objekt über die Klassenfactory erstellt Ruft einen direkten Zeiger auf das Objekt. Dies unterscheidet sich Singlethreaded prozessintern Objekte, die wichtigste Station des Clients Ruft einen direkten Zeiger auf das Objekt und alle anderen Stationen, die den Zugriff auf das Objekt über einen Proxy Gewinn zu erstellen. Da zwischen Marshallingvorgänge relativ direkten Aufruf langsam ist, kann Geschwindigkeit ändern einen Singlethread-prozessinternen Server für mehrere Stationen erheblich gesteigert werden.
  3. Prozessinterner Server, die nur MTA - unterstützt markiert mit ThreadingModel = frei:

    Ein Objekt dieser Server ist für den MTA. Implementiert eine eigene Synchronisierung und gleichzeitig von mehreren Clientthreads erfolgt. Diese Server haben Verhalten, die das STA-Modell inkompatibel ist. (Z. B. durch die Verwendung der Windows-Nachrichtenwarteschlange auf eine Weise, die die STA-Meldungsverteilschleife unterbrochen) Auch Threadmodell des Objekts als "Frei" markieren, die Implementierung des Objekts ist besagt Folgendes: dieses Objekts kann von einem beliebigen Clientthread aufgerufen werden, aber dieses Objekt auch kann übergeben Schnittstellenzeigern direkt (ohne Marshallen) Threads, der erstellt wurde und diese Threads können Anrufe über diesen Zeiger. Wenn der Client einen Schnittstellenzeiger auf ein Objekt Client implementiert (z. B. eine Senke) für dieses Objekt übergibt, kann es daher wieder durch diesen Schnittstellenzeiger aus jedem Thread aufrufen, der Sie erstellt, wählen. Wenn der Client ein STA, wird ein direkter Aufruf aus einem Thread die Threads, die das Empfängerobjekt erstellt (wie in 2) werden. COM stellt daher immer sicher, dass Clients in einem STA zugeordneten Threads auf diese Art von prozessinternen Objekt nur über einen Proxy zugreifen. Außerdem sollten diese Objekte nicht mit den Freethreadmarshaller aggregiert, da, die direkt auf STA-Threads ausgeführt werden können.
  4. Prozessinternen Server, Apartmentmodell und free-threading - unterstützt, markiert mit ThreadingModel = beides:

    Ein Objekt von diesem Server implementiert eine eigene Synchronisierung und erfolgt gleichzeitig mehrere Clientapartments. Darüber hinaus erstellt dieses Objekt und verwendeten direkt, über einen Proxy Stationen oder der MTA einen Clientprozess. Da dieses Objekt direkt in Stationen verwendet wird, muss der Server Schnittstellen Objekte möglicherweise von anderen Servern zwischen Threads der Zugriff auf ein Objekt so threading entsprechende garantiert marshallen. Auch Threadmodell des Objekts 'Both' markieren, die Implementierung des Objekts ist besagt Folgendes: dieses Objekts kann von einem beliebigen Clientthread aufgerufen werden, aber alle Rückrufe dieses Objekt auf dem Client erfolgt nur auf das Objekt den Schnittstellenzeiger auf das Rückrufobjekt erhielt Apartment. COM ermöglicht ein Objekts direkt in einem STA ebenso wie ein MTA den Clientprozess erstellt werden.

    Da Wohnung, die ein Objekt immer erstellt einen direkten Zeiger als Proxy Zeiger erhält, bieten ThreadingModel "Both" Objekte Leistungssteigerungen ThreadingModel "Frei" Objekte beim Laden in STA.

    Da ein ThreadingModel "Both"-Objekt auch MTA Zugriff vorgesehen ist (es ist vollständig threadsicher intern), können sie Leistung mit der Marshaller CoCreateFreeThreadedMarshaler vorgesehenen aggregieren beschleunigen. Dieses Objekt vom System bereitgestellten für aufrufende Objekte im aggregiert, und benutzerdefinierte marshallt direkte Verweise auf das Objekt in allen Apartments im Prozess. Clients in Wohnung, möglicherweise STA oder MTA, dann das Objekt direkt statt über einen Proxy zugreifen. Beispielsweise ein STA-Modell Client erstellt das Objekt prozessintern in STA1 und marshallt das Objekt STA2. Wenn das Objekt nicht mit den Freethreadmarshaller aggregiert, erhält STA2 Zugriff auf das Objekt über einen Proxy. Ist dies der Fall ist, bietet der Freethread-Marshaller STA2 einen direkten Zeiger auf das Objekt

    Hinweis: achten bei der Freethread-Marshaller aggregieren. Angenommen Sie, ein Objekt, das als ThreadingModel "Beide" (und auch mit den Freethreadmarshaller aggregieren) markiert ist ein ein Schnittstellenzeiger auf ein anderes Objekt ist, dessen ThreadingModel "Apartment" handelt. Annehmen Sie, dass eine Station das erste Objekt erstellt und während der Erstellung das erste Objekt das zweite Objekt erstellt. Nach den oben beschriebenen Regeln hält das erste Objekt nun einen direkten Zeiger auf das zweite Objekt. Nehmen wir nun an die Station den Schnittstellenzeiger auf das erste Objekt auf einem anderen Apartment marshallt. Da die ersten Objekt Aggregate frei-Marshaller Thread erhält ein direkter Zeiger auf das erste Objekt das zweite Apartment. Wenn das zweite Apartment dann über diesen Zeiger aufruft und dieser Aufruf bewirkt, dass das erste Objekt durch den Schnittstellenzeiger auf das zweite Objekt aufrufen, ist ein Fehler aufgetreten, da das zweite Objekt nicht direkt von der zweiten Apartment aufgerufen werden soll. Hält das erste Objekt einen Zeiger auf einen Proxy für das zweite Objekt als einen direkten Zeiger, verursacht dies einen anderen Fehler. System-Proxys auch COM-Objekte sind nur ein Apartment zugeordnet. Sie behalten die Übersicht ihrer Wohnung um bestimmte Circularities zu vermeiden. So erhalten ein Objekt einen Proxy verbunden mit einem anderen als dem Thread, auf dem das Objekt ausgeführt wird fordert der Rückgabewert RPC_E_WRONG_THREAD von der Proxy und der Aufruf schlägt fehl.

Threading-Modell Interoperabilität zwischen Clients und In-Process-Objekte

Alle Kombinationen von threading Model Interoperabilität dürfen Betweenclients und in-Process-Objekte.

COM ermöglicht allen Modell STA Clients arbeiten mit einem Threadingin Proc-Objekte erstellen und Zugriff auf das Objekt in dem Client MainSTA Marshalling an den Client-Station, die [Ex] CoCreateInstance aufgerufen.

"Host" STA im Client schafft ein MTA in einem Client ein STA-Modell prozessinternen läuft COM. Dieser Host STA erstellt das Objekt und dieses Zeigers zurück gemarshallt wird. Ebenso läuft bei einer STAcreates ein MTA prozessinternen COM Host-MTA in der Objectis erstellt und an die Station Interoperabilität zwischen Thesingle-threading und MTA-Modell gemarshallt ähnlich behandelt wird Thesingle-threading-Modell ist nur ein degenerierter Fall das STA-Modell.

Marshallen von Code für eine benutzerdefinierte Schnittstelle vorzulegen, die in Procserver implementiert, will es Interoperabilität unterstützt, die COMto Marshal Schnittstelle Clientapartments erfordert. Siehe REFERENCESsection unten für Weitere Informationen.

Beziehung zwischen Threadmodell und Klassenfactoryobjekt zurückgegeben

Eine genaue Definition von prozessinternen Servern wird "geladen" Apartments Isexplained in den beiden folgenden Schritten:

  1. DLL mit prozessinternen Server-Klasse hat keine zuvor geladenen (Prozess-Adressbereich zugeordnet) vom Ladeprogramm Betriebssystems, Vorgang ausgeführt und COM erhält die Adresse der DLLGetClassObject-Funktion, die von der DLL exportiert. DLL von Wohnung zugeordneten Threads bereits geladen wurde, wird dieser Schritt übersprungen.
  2. COM verwendet den Thread (oder im Falle eines Threads MTA) zugeordneten Apartment "laden", um die CLSID der Klasse benötigten DLL exportierte DllGetClassObject-Funktion aufzurufen. Das Factory-Objekt zurückgegeben wird dann zum Erstellen von Instanzen von Objekten der Klasse.

    Der zweite Schritt (Aufruf der DllGetClassObject von COM) tritt jedes Mal, das ein Client in demselben Apartment CoGetClassObject/CoCreateIntance [Ex] selbst aufruft. Anders gesagt kann DllGetClassObject oft von demselben Apartment zugeordneten Threads aufgerufen werden. Alles hängt davon ab, wie viele Clients in diesem Apartment versuchen, Zugriff auf eine Factory für die Klasse.
Autoren der Klasse Implementierung und der Autor des DLLpackage einer bestimmten Gruppe von Klassen haben freie Whatfactory Objekt zurück auf DllGetClassObject Functioncall entscheiden. Der Autor des Pakets DLL hat die letztendlich da Code "hinter" der einzelnen DLL Wide DllGetClassObject() Einstiegspunkt welche Merkmal erste und letzte möglicherweise entscheiden, was zu tun ist. Threetypical sind:

  1. DllGetClassObject gibt eine eindeutige Klassenfactoryobjekt pro aufrufenden Thread (d.h. ein Klassenfactoryobjekt pro Station und möglicherweise mehrere Klassenfactories innerhalb der MTA).
  2. DllGetClassObject gibt immer die gleiche Klassenfactoryobjekt unabhängig von der Identität der aufrufende Thread oder das Apartment aufrufenden Thread zugeordnet.
  3. DllGetClassObject gibt eine eindeutige Klassenfactoryobjekt pro Aufruf (eine pro STA und MTA).
Andere Optionen für die Beziehung zwischen Aufrufe ToDllGetClassObject und Klassenfactoryobjekt zurückgegeben (z. B. wird als neu Factoryobjekt pro Aufruf DllGetClassObject class) aber sie Notpresently besonders werden angezeigt.

Übersicht über Client und Threadmodellen prozessinternen Server-Objekt

Die folgende Tabelle zeigt die Interaktion zwischen Differentthreading bei einem Client Thread ruft zuerst CoGetClassObject für Aclass als prozessinterner Server implementiert.

Arten von Kunden-Threads:

  • Client in einem Thread zugeordnet "main" STA ausgeführt (erste Thread CoInitialize oder CoInitializeEx mit COINIT_APARTMENTTHREADED-Flag aufrufen)-Aufrufen dieser STA0 (auch als single - threading-Modell).
  • Client wird in einer anderen Station [ASCII 150]-Aufruf zugeordneten Threads dieser Station * ausgeführt.
  • Client wird im MTA zugeordneten Threads ausgeführt.
Arten von DLL-Servern:

  • Server ist kein Schlüssel ThreadingModel--aufgerufen "None".
  • Server als "Apartment" gekennzeichnet – rufen Sie dieses "Apt."
  • Server als "Frei" gekennzeichnet.
  • Server zeichnet "Beide".
Lesen die Tabelle beachten die Definition oben erstellt einen Server in einem Apartment "laden".
Client     Server     Result------     ------     -----------------------------------------STA0       None       Direct access; server loaded into STA0STA*       None       Proxy access; server loaded into                      STA0.MTA        None       Proxy access; server loaded into STA0; STA0 created                      automatically by COM if necessary;STA0       Apt        Direct access; server loaded into STA0STA*       Apt        Direct access; server loaded into STA*MTA        Apt        Proxy access; server loaded into anSTA created automatically by COM.STA0       Free       Proxy access; server is loaded into MTAMTA created automatically by COM if necessary.STA*       Free       Same as STA0->FreeMTA        Free       Direct accessSTA0       Both       Direct access; server loaded into STA0STA*       Both       Direct access; server loaded into STA*MTA        Both       Direct access; server loaded into the MTA				
Informationsquellen
SDK-Dokumentation für CoRegisterMessageFilter() und IMessageFilterinterface.

Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:
136885 OLE-Threads müssen Nachrichten weiterleitet.
137629 In-Proc-Objekt benutzerdefinierte Schnittstelle im Apartment-Modell-Client

Warnung: Dieser Artikel wurde automatisch übersetzt.

خصائص

رقم الموضوع: 150777 - آخر مراجعة: 10/26/2015 02:11:00 - المراجعة: 5.0

  • kbinfo kbmt KB150777 KbMtde
تعليقات