Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 een beheerde thread. 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.
Koppeling van Win32-threading naar beheerde threading
In de volgende tabel worden Win32 thread-elementen gecorreleerd met hun geschatte runtime-equivalent. Let op dat deze koppeling 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 |
| Slapen | Thread.Sleep |
| WaitForSingleObject op het thread-handvat | Thread.Join |
| ExitThread | Geen equivalent |
| GetCurrentThread- | Thread.CurrentThread |
| SetThreadPriority | Thread.Priority |
| Geen equivalent | Thread.Name |
| Geen equivalent | Thread.IsBackground |
| In de buurt van CoInitializeEx (OLE32.DLL) | Thread.ApartmentState |
Beheerde threads en COM-appartementen
Een beheerde thread kan worden gemarkeerd om aan te geven dat deze een single-threaded of multithreaded appartement host. (Zie Processen, Threads en Appartementen voor meer informatie over de COM-threadingarchitectuur.) De GetApartmentState, SetApartmentStateen TrySetApartmentState methoden van de Thread klasse retourneren en de appartementsstatus van een thread toewijzen. Als de status niet is ingesteld, retourneert GetApartmentStateApartmentState.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 threads-onafhankelijke manier. De enige beheerde objecten die dit vrije threadgedrag niet vertonen, zijn objecten die zijn afgeleid van ServicedComponent of StandardOleMarshalObject.
In de beheersomgeving is er geen ondersteuning voor de SynchronizationAttribute, tenzij u contexten en contextgebonden beheerde instanties gebruikt. Als u Enterprise Services gebruikt, dient uw object afgeleid te zijn van ServicedComponent (dat zelf is afgeleid van ContextBoundObject).
Wanneer beheerde code com-objecten aanroept, volgt deze altijd COM-regels. Met andere woorden, het maakt gebruik van COM apartment proxy's en COM+ 1.0 context wrappers, zoals bepaald door OLE32.
Blokkeringsproblemen
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, markeert de runtime de thread voor afbreken en neemt de controle over wanneer deze opnieuw de 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, GC.WaitForPendingFinalizers, enzovoort, zijn allemaal responsief op Thread.Interrupt en 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.
Zie ook
Met ons samenwerken op GitHub
De bron voor deze inhoud vindt u op GitHub, waar u ook problemen en pull-aanvragen kunt maken en controleren. Bekijk onze gids voor inzenders voor meer informatie.
