Beheerde en onbeheerde threading in Windows
Het beheer van alle threads wordt uitgevoerd via de Thread klasse, inclusief threads die zijn gemaakt door de algemene taalruntime en threads die zijn gemaakt buiten de runtime die de beheerde omgeving invoeren om code uit te voeren. De runtime bewaakt alle threads in het proces die ooit code hebben uitgevoerd in de beheerde uitvoeringsomgeving. Er worden geen andere threads bijgehouden. Threads kunnen de beheerde uitvoeringsomgeving invoeren via COM-interoperabiliteit (omdat de runtime beheerde objecten als COM-objecten beschikbaar maakt voor de onbeheerde wereld), de functie COM DllGetClassObject en platformaanroepen.
Wanneer een onbeheerde thread de runtime binnenkomt via bijvoorbeeld een aanroepbare COM-wrapper, controleert het systeem het thread-lokale archief van die thread om te zoeken naar een intern beheerd Thread object. Als er een wordt gevonden, is de runtime al op de hoogte van deze thread. Als er echter geen object kan worden gevonden, bouwt de runtime een nieuw Thread object en installeert het in de thread-local store van die thread.
In beheerde threading Thread.GetHashCode is de stabiele identificatie van beheerde threads. Voor de levensduur van uw thread komt deze niet in conflict met de waarde van een andere thread, ongeacht het toepassingsdomein waaruit u deze waarde verkrijgt.
Toewijzing van Win32-threading aan beheerde threading
In de volgende tabel worden Win32-threading-elementen toegewezen aan hun geschatte runtime-equivalent. Houd er rekening mee dat deze toewijzing geen identieke functionaliteit vertegenwoordigt. TerminateThread voert bijvoorbeeld geen definitieve componenten uit of maakt resources vrij en kan niet worden voorkomen. Thread.Abort Voert echter al uw terugdraaicode uit, maakt alle resources vrij en kan worden geweigerd met behulp van ResetAbort. Lees de documentatie goed voordat u veronderstellingen over functionaliteit maakt.
| In Win32 | In de algemene taalruntime |
|---|---|
| CreateThread | Combinatie van thread en ThreadStart |
| TerminateThread | Thread.Abort |
| SuspendThread | Thread.Suspend |
| CvThread | Thread.Resume |
| Slaap | Thread.Sleep |
| WaitForSingleObject op de thread-ingang | Thread.Join |
| ExitThread | Geen equivalent |
| GetCurrentThread | Thread.CurrentThread |
| SetThreadPriority | Thread.Priority |
| Geen equivalent | Thread.Name |
| Geen equivalent | Thread.IsBackground |
| Dicht bij CoInitializeEx (OLE32.DLL) | Thread.ApartmentState |
Beheerde threads en COM-appartementen
Een beheerde thread kan worden gemarkeerd om aan te geven dat deze een appartement met één thread of multithreaded host. (Zie voor meer informatie over de COM-threadingarchitectuur Processen, threads en appartementen.) De GetApartmentState, SetApartmentStateen TrySetApartmentState methoden van de Thread klasse retourneren en de appartementsstatus van een thread toewijzen. Als de status niet is ingesteld, GetApartmentState wordt deze geretourneerd ApartmentState.Unknown.
De eigenschap kan alleen worden ingesteld wanneer de thread de ThreadState.Unstarted status heeft. De eigenschap kan slechts één keer worden ingesteld voor een thread.
Als de status van het appartement niet is ingesteld voordat de thread wordt gestart, wordt de draad geïnitialiseerd als een multithreaded appartement (MTA). De finalizer-thread en alle threads die worden beheerd door ThreadPool zijn MTA.
Belangrijk
Voor de opstartcode van de toepassing is de enige manier om de status van het appartement te beheren door de MTAThreadAttribute of de STAThreadAttribute procedure voor het toegangspunt toe te passen.
Beheerde objecten die worden blootgesteld aan COM gedragen zich alsof ze de free threaded marshaller hadden samengevoegd. Met andere woorden, ze kunnen worden aangeroepen vanuit elk COM-appartement op een vrije thread. De enige beheerde objecten die dit vrije threadgedrag niet vertonen, zijn objecten die zijn afgeleid van ServicedComponent of StandardOleMarshalObject.
In de beheerde wereld is er geen ondersteuning voor de SynchronizationAttribute tenzij u contexten en contextgebonden beheerde exemplaren gebruikt. Als u Enterprise Services gebruikt, moet uw object zijn afgeleid ServicedComponent van (die zelf is afgeleid van ContextBoundObject).
Wanneer beheerde code com-objecten aanroept, volgt deze altijd COM-regels. Met andere woorden, het roept via COM appartement proxy's en COM+ 1.0 context wrappers zoals bepaald door OLE32.
Blokkerende problemen
Als een thread een onbeheerde aanroep uitvoert in het besturingssysteem dat de thread in niet-beheerde code heeft geblokkeerd, heeft de runtime geen controle over Thread.Interrupt of Thread.Abort. In het geval van Thread.Abort, de runtime markeert de thread voor afbreken en neemt de controle over wanneer deze opnieuw beheerde code invoert. Het verdient de voorkeur dat u beheerde blokkeringen gebruikt in plaats van onbeheerde blokkeringen. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, , , Thread.Join, enzovoort GC.WaitForPendingFinalizers, zijn allemaal responsief op Thread.Interrupt en naar Thread.Abort. Als uw thread zich in een appartement met één thread bevindt, worden al deze beheerde blokkerende bewerkingen correct in uw appartement gepompt terwijl uw thread wordt geblokkeerd.
Threads en vezels
Het .NET-threadingmodel biedt geen ondersteuning voor vezels. U moet geen onbeheerde functie aanroepen die wordt geïmplementeerd met behulp van vezels. Dergelijke aanroepen kunnen leiden tot een crash van de .NET-runtime.
