Freigeben über

Verwaltetes und nicht verwaltetes Thread-Management in Windows

Die Verwaltung aller Threads erfolgt über die Thread Klasse, einschließlich Threads, die von der Common Language Runtime erstellt wurden und solche, die außerhalb der Laufzeit erstellt wurden und in die verwaltete Umgebung eintreten, um Code auszuführen. Die Laufzeit überwacht alle Threads im Prozess, die jemals Code in der verwalteten Ausführungsumgebung ausgeführt haben. Es verfolgt keine anderen Threads. Threads können die verwaltete Ausführungsumgebung über COM-Interoperabilität betreten (da die Laufzeit verwaltete Objekte als COM-Objekte für die nicht verwaltete Welt verfügbar macht), die COM DllGetClassObject-Funktion und Plattformaufrufe.

Wenn ein nicht verwalteter Thread beispielsweise über einen COM-aufrufbaren Wrapper in die Laufzeitumgebung eintritt, überprüft das System den threadspezifischen Speicher dieses Threads, um nach einem internen verwalteten Thread Objekt zu suchen. Wenn ein Thread gefunden wird, ist die Laufzeitumgebung bereits mit ihm vertraut. Wenn das Objekt jedoch nicht gefunden werden kann, erstellt die Laufzeit ein neues Thread Objekt und installiert es im threadlokalen Speicher dieses Threads.

Bei verwaltetem Threading handelt es sich um die stabile verwaltete Threadidentifikation Thread.GetHashCode . Für die Lebensdauer des Threads wird es nicht mit dem Wert eines anderen Threads kollidieren, unabhängig von der Anwendungsdomäne, aus der Sie diesen Wert abrufen.

Zuordnung von Win32-Threading zu verwaltetem Threading

Die folgende Tabelle ordnet Win32-Threadingelemente ihrer ungefähren Laufzeitentsprechung zu. Beachten Sie, dass diese Zuordnung keine identische Funktionalität darstellt. " TerminateThread " führt beispielsweise keine endgültigen Klauseln aus oder gibt Ressourcen frei und kann nicht verhindert werden. Thread.Abort führt jedoch den gesamten Rollback-Code aus, gibt alle Ressourcen zurück und kann mittels ResetAbort verweigert werden. Lesen Sie die Dokumentation unbedingt genau, bevor Sie Annahmen zur Funktionalität treffen.

Im Win32-System In der Common Language Runtime
CreateThread- Kombination aus Thread und ThreadStart
TerminateThread Thread.Abort
SuspendThread Thread.Suspend
ResumeThread Thread.Resume
Schlafen Thread.Sleep
WaitForSingleObject im Threadhandle Thread.Join
ExitThread- Keine Entsprechung
GetCurrentThread Thread.CurrentThread
SetThreadPriority Thread.Priority
Keine Entsprechung Thread.Name
Keine Entsprechung Thread.IsBackground
Nahe an CoInitializeEx (OLE32.DLL) Thread.ApartmentState

Verwaltete Threads und COM-Apartments

Ein verwalteter Thread kann markiert werden, um anzugeben, dass er ein Single-Threaded-Apartment oder Multithreaded-Apartment hosten wird. (Weitere Informationen zur COM-Threadingarchitektur finden Sie unter "Prozesse", "Threads" und "Apartments".) Die Methoden GetApartmentState, SetApartmentState und TrySetApartmentState der Thread Klasse geben den Apartmentzustand eines Threads zurück und weisen ihn zu. Wurde der Zustand nicht festgelegt, gibt GetApartmentState den Wert ApartmentState.Unknown zurück.

Die Eigenschaft kann nur festgelegt werden, wenn sich der Thread im ThreadState.Unstarted Zustand befindet. Sie kann nur einmal für einen Thread festgelegt werden.

Wenn der Apartmentzustand nicht festgelegt ist, bevor der Thread gestartet wird, wird der Thread als Multithread-Apartment (MTA) initialisiert. Der Finalizerthread und alle Threads unter der Kontrolle von ThreadPool sind MTA.

Von Bedeutung

Bei Anwendungsstartcode besteht die einzige Möglichkeit zum Steuern des Apartmentstatus darin, MTAThreadAttribute oder STAThreadAttribute für das Einstiegspunktverfahren anzuwenden.

Verwaltete Objekte, die für COM verfügbar gemacht werden, verhalten sich, als hätten sie den Freethread-Marshaller aggregiert. Anders gesagt können Sie von jedem COM-Apartment auf eine Freethreadweise aufgerufen werden. Die einzigen verwalteten Objekte, die dieses Freethread-Verhalten nicht zeigen, die Objekte, die von ServicedComponent oder StandardOleMarshalObject abgeleitet werden.

In der verwalteten Welt gibt es keine Unterstützung für die SynchronizationAttribute, es sei denn, Sie verwenden Kontexte und kontextgebundene verwaltete Instanzen. Wenn Sie Enterprise Services verwenden, muss Ihr Objekt von ServicedComponent abgeleitet werden, das selbst von ContextBoundObject abgeleitet ist.

Wenn verwalteter Code COM-Objekte aufruft, folgt er immer COM-Regeln. Anders gesagt erfolgt der Aufruf über COM-Apartmentproxies und COM+ 1.0-Kontext-Wrapper, wie von OLE32 vorgegeben.

Blockieren von Problemen

Wenn ein Thread einen nicht verwalteten Aufruf an das Betriebssystem vornimmt, das den Thread im nicht verwalteten Code blockiert hat, übernimmt die Laufzeit nicht die Steuerung für Thread.Interrupt oder Thread.Abort. Im Fall von Thread.Abortkennzeichnet die Laufzeit den Thread für Abort und übernimmt die Kontrolle darüber, wenn der verwaltete Code erneut eingegeben wird. Es empfiehlt sich, verwaltete Blockierungen anstelle nicht verwalteter Blockierungen zu verwenden. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, , Monitor.EnterMonitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizersusw. reagieren alle auf Thread.Interrupt und auf Thread.Abort. Wenn sich Ihr Thread in einem Singlethread-Apartment befindet, werden all diese verwalteten Blockierungsvorgänge außerdem Meldungen in Ihr Apartment verschieben, während Ihr Thread blockiert ist.

Fäden und Fasern

Das .NET-Threadingmodell unterstützt keine Fasern. Sie sollten keine nicht verwaltete Funktion aufrufen, die mithilfe von Fasern implementiert wird. Solche Aufrufe können zu einem Absturz der .NET-Laufzeit führen.

Siehe auch