Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La administración de todos los subprocesos se realiza a través de la Thread clase , incluidos los subprocesos creados por Common Language Runtime y los creados fuera del tiempo de ejecución que entran en el entorno administrado para ejecutar código. El runtime supervisa todos los subprocesos del proceso que han ejecutado alguna vez código en el entorno de ejecución administrado. No realiza un seguimiento de ningún otro subproceso. Los subprocesos pueden acceder al entorno de ejecución administrado a través de la interoperabilidad COM (porque el runtime expone los objetos administrados como objetos COM a los entornos no administrados), la función COM DllGetClassObject y la invocación de plataforma.
Cuando un subproceso no administrado entra en el runtime a través de, por ejemplo, un contenedor CCW, el sistema comprueba el almacén local del subproceso para buscar un objeto Thread administrado interno. Si se encuentra uno, el entorno de ejecución ya conoce este subproceso. Sin embargo, si no encuentra uno, el tiempo de ejecución compila un nuevo Thread objeto e lo instala en el almacén local de subprocesos de ese subproceso.
En los subprocesos administrados, Thread.GetHashCode es la identificación del subproceso administrado estable. Durante la vigencia del subproceso, no colisionará con el valor de ningún otro subproceso, independientemente del dominio de aplicación desde el que obtenga este valor.
Asignación de subprocesos de Win32 a subprocesos administrados
En la tabla siguiente se asignan los elementos de subprocesamiento de Win32 a sus equivalentes aproximados en tiempo de ejecución. Tenga en cuenta que este mapeo no ofrece una funcionalidad idéntica. Por ejemplo, TerminateThread no ejecuta cláusulas finally ni libera recursos y no se puede evitar. Sin embargo, Thread.Abort ejecuta todo el código de reversión, reclama todos los recursos y puede ser denegado usando ResetAbort. Asegúrese de leer la documentación detenidamente antes de realizar suposiciones sobre la funcionalidad.
| En Win32 | En el entorno de ejecución del lenguaje común |
|---|---|
| CreateThread | Combinación de Thread y ThreadStart |
| TerminateThread | Thread.Abort |
| SuspendThread | Thread.Suspend |
| ResumeThread | Thread.Resume |
| Dormir | Thread.Sleep |
| WaitForSingleObject en el identificador de subproceso | Thread.Join |
| ExitThread | Sin equivalente |
| GetCurrentThread | Thread.CurrentThread |
| SetThreadPriority | Thread.Priority |
| Sin equivalente | Thread.Name |
| Sin equivalente | Thread.IsBackground |
| Cercano a CoInitializeEx (OLE32.DLL) | Thread.ApartmentState |
Subprocesos administrados y apartamentos COM
Un subproceso administrado se puede marcar para indicar que hospedará un contenedor uniproceso o multiproceso . (Para obtener más información sobre la arquitectura de subprocesos COM, vea Procesos, Subprocesos y Apartamentos.) Los métodos GetApartmentState, SetApartmentState y TrySetApartmentState de la clase Thread devuelven y asignan el estado de apartamento de un subproceso. Si no se ha establecido el estado, GetApartmentState devuelve ApartmentState.Unknown.
La propiedad solo se puede establecer cuando el subproceso está en estado ThreadState.Unstarted ; solo se puede establecer una vez para un subproceso.
Si el estado de contenedor no se establece antes de que se inicie el subproceso, el subproceso se inicializa como un contenedor multiproceso (MTA). El subproceso del finalizador y todos los subprocesos controlados por ThreadPool son MTA.
Importante
Para el código de inicio de aplicación, la única manera de controlar el estado de contenedor es aplicar MTAThreadAttribute o STAThreadAttribute al procedimiento de punto de entrada.
Los objetos administrados que están expuestos a COM se comportan como si tuviesen agregado el cálculo de referencias con subprocesamiento libre. En otras palabras, se pueden llamar desde cualquier apartamento COM en un modo de subprocesamiento libre. Los únicos objetos administrados que no muestran este comportamiento de subprocesamiento libre son aquellos que derivan de ServicedComponent o StandardOleMarshalObject.
En el ámbito de recursos administrados, SynchronizationAttribute no se admite a menos que se usen contextos e instancias administradas asociadas a un contexto. Si usa Enterprise Services, el objeto debe derivarse de ServicedComponent (que se deriva de ContextBoundObject).
Cuando el código administrado llama a objetos COM, siempre sigue las reglas COM. En otras palabras, el código llama a través de los proxy de apartamentos COM y contenedores de contexto COM+ 1.0, según lo dictado por OLE32.
Problemas de bloqueo
Si un subproceso realiza una llamada no administrada al sistema operativo que ha bloqueado el subproceso en código no administrado, el tiempo de ejecución no tomará el control de él para Thread.Interrupt o Thread.Abort. En el caso de Thread.Abort, el runtime marca el subproceso para Abort y toma el control de él cuando vuelve a introducir código administrado. Es preferible usar bloqueo administrado en lugar de bloqueo no administrado. WaitHandle.WaitOne,WaitHandle.WaitAny, , WaitHandle.WaitAllMonitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizersetc., responden a Thread.Interrupt y a Thread.Abort. Además, si su subproceso está en un contenedor uniproceso, todas estas operaciones de bloqueo administrado suministrarán correctamente mensajes en su contenedor mientras el subproceso está bloqueado.
Hilos y fibras
El modelo de subprocesos de .NET no admite fibras. No debe llamar a ninguna función no administrada que se implementa mediante fibras. Estas llamadas pueden dar lugar a un bloqueo del entorno de ejecución de .NET.
Consulte también
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
