Zarządzane i niezarządzane wątki w systemie Windows
Zarządzanie wszystkimi wątkami odbywa się za pośrednictwem Thread klasy, w tym wątków utworzonych przez środowisko uruchomieniowe języka wspólnego i utworzonych poza środowiskiem uruchomieniowym, które wchodzą w środowisko zarządzane do wykonywania kodu. Środowisko uruchomieniowe monitoruje wszystkie wątki w procesie, które kiedykolwiek wykonywały kod w zarządzanym środowisku wykonywania. Nie śledzi żadnych innych wątków. Wątki mogą wprowadzać zarządzane środowisko wykonywania za pośrednictwem międzyoperacyjności MODELU COM (ponieważ środowisko uruchomieniowe uwidacznia zarządzane obiekty jako obiekty COM w świecie niezarządzanych), funkcję COM DllGetClassObject i wywołanie platformy.
Gdy niezarządzany wątek wchodzi do środowiska uruchomieniowego za pośrednictwem na przykład otoki wywołującej com, system sprawdza magazyn wątków lokalnych tego wątku, aby wyszukać wewnętrzny obiekt zarządzany Thread . Jeśli jeden z nich zostanie znaleziony, środowisko uruchomieniowe jest już świadome tego wątku. Jeśli jednak nie można go znaleźć, środowisko uruchomieniowe skompiluje nowy Thread obiekt i zainstaluje go w magazynie wątku lokalnego tego wątku.
W zarządzanym wątkowaniu Thread.GetHashCode jest stabilna identyfikacja wątków zarządzanych. Przez okres istnienia wątku nie będzie on kolidować z wartością z żadnego innego wątku, niezależnie od domeny aplikacji, z której uzyskasz tę wartość.
Mapowanie z wątków Win32 do zarządzanego wątkowania
Poniższa tabela mapuje elementy wątkowe Win32 na przybliżony odpowiednik środowiska uruchomieniowego. Należy pamiętać, że to mapowanie nie reprezentuje identycznych funkcji. Na przykład funkcja TerminateThread nie wykonuje klauzul w końcu ani nie zwalnia zasobów i nie można jej zapobiec. Jednak Thread.Abort wykonuje cały kod wycofywania, odzyskuje wszystkie zasoby i może zostać odrzucony przy użyciu polecenia ResetAbort. Pamiętaj, aby dokładnie przeczytać dokumentację przed wprowadzeniem założeń dotyczących funkcjonalności.
| W systemie Win32 | W środowisku uruchomieniowym języka wspólnego |
|---|---|
| Createthread | Połączenie wątku iThreadStart |
| TerminateThread | Thread.Abort |
| SuspendThread | Thread.Suspend |
| ResumeThread | Thread.Resume |
| Snu | Thread.Sleep |
| WaitForSingleObject na dojściu wątku | Thread.Join |
| Exitthread | Brak odpowiednika |
| GetCurrentThread | Thread.CurrentThread |
| SetThreadPriority | Thread.Priority |
| Brak odpowiednika | Thread.Name |
| Brak odpowiednika | Thread.IsBackground |
| Blisko coInitializeEx (OLE32.DLL) | Thread.ApartmentState |
Zarządzane wątki i apartamenty COM
Zarządzany wątek można oznaczyć, aby wskazać, że będzie on hostował jednowątkowy lub wielowątkowy apartament. (Aby uzyskać więcej informacji na temat architektury wątków COM, zobacz Procesy, wątki i apartamenty). Metody GetApartmentStateThread , SetApartmentStatei TrySetApartmentState klasy zwracają i przypisują stan mieszkania wątku. Jeśli stan nie został ustawiony, GetApartmentState zwraca wartość ApartmentState.Unknown.
Właściwość można ustawić tylko wtedy, gdy wątek jest w ThreadState.Unstarted stanie . Można ją ustawić tylko raz dla wątku.
Jeśli stan mieszkania nie jest ustawiony przed rozpoczęciem wątku, wątek jest inicjowany jako wielowątkowy apartament (MTA). Wątek finalizatora i wszystkie wątki kontrolowane przez usługę ThreadPool to MTA.
Ważne
W przypadku kodu uruchamiania aplikacji jedynym sposobem kontrolowania stanu mieszkania jest zastosowanie MTAThreadAttribute metody lub STAThreadAttribute do procedury punktu wejścia.
Zarządzane obiekty, które są narażone na modelu COM zachowują się tak, jakby zagregowały bezwątkowy marshaller. Innymi słowy, mogą być wywoływane z dowolnego mieszkania COM w sposób bezwątkowy. Jedynymi zarządzanymi obiektami, które nie wykazują tego zachowania bezwątkowy, są te obiekty pochodzące z lub ServicedComponentStandardOleMarshalObject.
W świecie zarządzanym nie ma obsługi, SynchronizationAttribute chyba że używasz kontekstów i powiązanych z kontekstem wystąpień zarządzanych. Jeśli korzystasz z usług Enterprise Services, obiekt musi pochodzić z ServicedComponent (który sam pochodzi z ContextBoundObjectklasy ).
Gdy kod zarządzany wywołuje obiekty COM, zawsze jest zgodny z regułami COM. Innymi słowy, wywołuje za pośrednictwem serwerów proxy mieszkań COM i otoki kontekstu COM+ 1.0 zgodnie z dyktowanym przez OLE32.
Problemy z blokowaniem
Jeśli wątek wykonuje niezarządzane wywołanie do systemu operacyjnego, który zablokował wątek w kodzie niezarządzanym, środowisko uruchomieniowe nie przejmie kontroli nad nim ani Thread.InterruptThread.Abort. W przypadku Thread.Abortprogramu środowisko uruchomieniowe oznacza wątek abort i przejmuje kontrolę nad nim podczas ponownego wprowadzania kodu zarządzanego. Preferowane jest użycie blokowania zarządzanego, a nie niezarządzanego blokowania. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, , Monitor.TryEnterMonitor.Enter, Thread.Join, GC.WaitForPendingFinalizersi tak dalej są dynamiczne do Thread.Interrupt i na Thread.Abort. Ponadto, jeśli wątek znajduje się w jednym wątku, wszystkie te zarządzane operacje blokowania będą poprawnie pompować komunikaty w mieszkaniu, gdy wątek jest zablokowany.
Wątki i włókna
Model wątkowania platformy .NET nie obsługuje światłowodów. Nie należy wywoływać żadnej niezarządzanej funkcji implementowanej przy użyciu włókien. Takie wywołania mogą spowodować awarię środowiska uruchomieniowego platformy .NET.
