Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La gestion de tous les threads est effectuée via la Thread classe, y compris les threads créés par le Common Language Runtime et ceux créés en dehors du runtime qui entrent dans l’environnement managé pour exécuter du code. Le runtime surveille tous les threads de son processus qui ont déjà exécuté du code dans l’environnement d’exécution managé. Il ne suit pas d’autres threads. Les threads peuvent entrer dans l’environnement d’exécution managé via l’interopérabilité COM (car le runtime expose des objets managés en tant qu’objets COM au monde non managé), à la fonction COM DllGetClassObject et à l’appel de plateforme.
Lorsqu’un thread non managé entre dans le runtime via, par exemple, un wrapper COM pouvant être appelé, le système vérifie le magasin local de threads de ce thread pour rechercher un objet managé Thread interne. Si l’un d’eux est trouvé, le runtime est déjà au courant de ce thread. S’il n’en trouve pas, toutefois, le runtime génère un nouvel Thread objet et l’installe dans le magasin local de threads de ce thread.
Dans le threading managé, Thread.GetHashCode est l’identification stable des threads managés. Pendant toute la durée de vie de votre thread, il n’entre en conflit avec la valeur d’aucun autre thread, quel que soit le domaine d’application à partir duquel vous obtenez cette valeur.
Mappage d’un thread Win32 à un threading managé
Le tableau suivant mappe les éléments de thread Win32 à leur équivalent d’exécution approximatif. Notez que ce mappage ne représente pas de fonctionnalités identiques. Par exemple, TerminateThread n’exécute pas de clauses finals ou libère des ressources et ne peut pas être empêché. Toutefois, Thread.Abort exécute tout votre code de restauration, récupère toutes les ressources et peut être refusé à l’aide ResetAbortde . Veillez à lire attentivement la documentation avant de faire des hypothèses sur les fonctionnalités.
| Dans Win32 | Dans le Common Language Runtime |
|---|---|
| CreateThread | Combinaison de threads et de threadsThreadStart |
| TerminateThread | Thread.Abort |
| SuspendThread | Thread.Suspend |
| ResumeThread | Thread.Resume |
| veille | Thread.Sleep |
| WaitForSingleObject sur le handle de thread | Thread.Join |
| ExitThread | Pas d'équivalent |
| GetCurrentThread | Thread.CurrentThread |
| SetThreadPriority | Thread.Priority |
| Pas d'équivalent | Thread.Name |
| Pas d'équivalent | Thread.IsBackground |
| Proche de CoInitializeEx (OLE32.DLL) | Thread.ApartmentState |
Threads managés et appartements COM
Un thread managé peut être marqué pour indiquer qu’il hébergera un appartement à thread unique ou multithread . (Pour plus d’informations sur l’architecture de thread COM, consultez Processus, Threads et Appartements.) Les GetApartmentStateméthodes et TrySetApartmentState les méthodes SetApartmentStatede la Thread classe retournent et attribuent l’état d’appartement d’un thread. Si l’état n’a pas été défini, GetApartmentState retourne ApartmentState.Unknown.
La propriété ne peut être définie que lorsque le thread est dans l’état ThreadState.Unstarted ; il ne peut être défini qu’une seule fois pour un thread.
Si l’état de l’appartement n’est pas défini avant le démarrage du thread, le thread est initialisé en tant qu’appartement multithread (MTA). Le thread finaliseur et tous les threads contrôlés par ThreadPool sont MTA.
Important
Pour le code de démarrage de l’application, la seule façon de contrôler l’état de l’appartement consiste à appliquer la MTAThreadAttribute procédure de point d’entrée ou à STAThreadAttribute celle du point d’entrée.
Les objets managés exposés à COM se comportent comme s’ils avaient agrégé le marshalleur à threads libres. En d’autres termes, ils peuvent être appelés à partir de n’importe quel appartement COM de manière libre. Les seuls objets managés qui n’affichent pas ce comportement sans thread sont ceux qui dérivent ou ServicedComponentStandardOleMarshalObject.
Dans le monde managé, il n’existe aucune prise en charge pour les SynchronizationAttribute cas où vous utilisez des contextes et des instances managées liées au contexte. Si vous utilisez Enterprise Services, votre objet doit dériver ServicedComponent (qui est lui-même dérivé de ContextBoundObject).
Lorsque le code managé appelle des objets COM, il suit toujours les règles COM. En d’autres termes, il appelle via des proxys d’appartement COM et des wrappers de contexte COM+ 1.0 comme dicté par OLE32.
Problèmes de blocage
Si un thread effectue un appel non managé dans le système d’exploitation qui a bloqué le thread dans du code non managé, le runtime ne prend pas le contrôle de celui-ci ou Thread.InterruptThread.Abort. Dans le cas de Thread.Abort, le runtime marque le thread pour Abort et prend le contrôle de celui-ci lorsqu’il entre à nouveau du code managé. Il est préférable d’utiliser le blocage managé plutôt que le blocage non managé. WaitHandle.WaitOne,WaitHandle.WaitAny, , WaitHandle.WaitAll, Monitor.TryEnterMonitor.Enter, Thread.Join, , GC.WaitForPendingFinalizers, et ainsi de suite sont tous réactifs à Thread.Interrupt et à Thread.Abort. En outre, si votre thread se trouve dans un appartement à thread unique, toutes ces opérations de blocage gérées pompent correctement les messages dans votre appartement pendant que votre thread est bloqué.
Threads et fibres
Le modèle de thread .NET ne prend pas en charge les fibres. Vous ne devez pas appeler une fonction non managée implémentée à l’aide de fibres. Ces appels peuvent entraîner un blocage du runtime .NET.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
