Share via


Subprocesamiento administrado y no administrado en Microsoft Windows

La administración de todos los subprocesos se realiza mediante la clase Thread, incluso la de los creados por Common Language Runtime o fuera del motor en tiempo de ejecución que entran en el entorno administrado para ejecutar el código. El motor en tiempo de ejecución supervisa todos los subprocesos de su proceso que han ejecutado código alguna vez dentro del entorno de ejecución administrado. No realiza el seguimiento de otros subprocesos. Los subprocesos pueden entrar en el entorno de ejecución administrado a través de la interoperabilidad COM (puesto que el motor en tiempo de ejecución expone los objetos administrados como objetos COM al universo no administrado), la función COM DllGetClassObject() y por invocación de plataforma.

Cuando un subproceso no administrado entra en el motor en tiempo de ejecución, por ejemplo, a través de un contenedor COM invocable, el sistema comprueba el almacenamiento local de los subprocesos de dicho subproceso para buscar un objeto administrado interno Thread. Si encuentra alguno, el motor en tiempo de ejecución ya está al corriente de este subproceso. No obstante, si no puede encontrar ninguno, compila un nuevo objeto Thread y lo instala en el almacenamiento local de subprocesos de dicho subproceso.

En el subprocesamiento administrado, Thread.GetHashCode es la identificación estable del subproceso administrado. Mientras dure el subproceso, no colisionará con el valor de ningún otro subproceso, independientemente del dominio de aplicación del que se obtenga este valor.

NotaNota

Un ThreadId del sistema operativo no tiene relación fija con un subproceso administrado, puesto que un host no administrado puede controlar la relación entre los subprocesos administrados y los no administrados.En concreto, un host sofisticado puede utilizar la API de fibra para programar muchos subprocesos administrados con el mismo subproceso del sistema operativo o para pasar un subproceso administrado entre diferentes subprocesos del sistema operativo.

Correspondencia entre el subprocesamiento de Win32 y el subprocesamiento administrado

En la tabla siguiente se asignan elementos del subprocesamiento de Win32 a su equivalente aproximado del motor en tiempo de ejecución. Tenga en cuenta que esta correspondencia no representa una funcionalidad idéntica. Por ejemplo, TerminateThread no ejecuta cláusulas finally ni libera recursos, y no se puede evitar. No obstante, Thread.Abort ejecuta todo el código para revertir, recupera todos los recursos y puede denegarse mediante ResetAbort. Lea atentamente la documentación antes de realizar suposiciones acerca de la funcionalidad.

En Win32

En Common Language Runtime

CreateThread

Combinación de Thread y ThreadStart

TerminateThread

Thread.Abort

SuspendThread

Thread.Suspend

ResumeThread

Thread.Resume

Sleep

Thread.Sleep

WaitForSingleObject en el controlador del subproceso

Thread.Join

ExitThread

Ningún equivalente

GetCurrentThread

Thread.CurrentThread

SetThreadPriority

Thread.Priority

Ningún equivalente

Thread.Name

Ningún equivalente

Thread.IsBackground

Próximo a CoInitializeEx (OLE32.DLL)

Thread.ApartmentState

Subprocesos administrados y apartamentos COM

Un subproceso administrado puede marcarse para indicar que no hospedará ningún apartamento de un único subproceso o un apartamento multiproceso. 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.

NotaNota

En las versiones 1.0 y 1.1 de .NET Framework, para obtener y establecer el estado de tipo apartamento se utiliza la propiedad ApartmentState.

La propiedad se puede establecer cuando el subproceso está en el estado ThreadState.Unstarted; no obstante, sólo se puede establecer una vez por subproceso.

Si no se establece el estado de apartamento antes de iniciar el subproceso, este último se inicializa como apartamento multiproceso (MTA). El subproceso finalizador y todos los subprocesos controlados por ThreadPool son MTA.

Nota importanteImportante

Para el código de inicio de la aplicación, la única manera de controlar el estado de tipo apartamento es aplicar MTAThreadAttribute o STAThreadAttribute al procedimiento de punto de entrada.En las versiones 1.0 y 1.1 de .NET Framework, la propiedad ApartmentState se puede establecer como la primera línea de código.Esto no está permitido en la versión 2.0 de .NET Framework.

Los objetos administrados que se exponen a COM se comportan como si hubieran agregado el contador de referencias de subprocesamiento libre. En otras palabras, se les puede llamar desde cualquier apartamento COM con subprocesamiento libre. Los únicos objetos administrados que no presentan este comportamiento de subproceso libre son los que se derivan de ServicedComponent.

En el universo administrado, no hay compatibilidad con el atributo SynchronizationAttribute, a menos que se utilicen contextos e instancias administradas enlazadas a un contexto. Si utiliza EnterpriseServices, el objeto debe derivar de ServicedComponent (que se deriva a su vez de ContextBoundObject).

Cuando el código administrado llama a objetos COM, siempre sigue reglas COM. En otras palabras, llama a través de un proxy de apartamento COM y contenedores de contexto COM+ 1.0, según dicta 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 motor en tiempo de ejecución no tomará el control del mismo para Thread.Interrupt o Thread.Abort. En el caso de Thread.Abort, el tiempo de ejecución marca el subproceso para Abort y toma control del mismo cuando vuelve a entrar en el código administrado. Es preferible utilizar el bloqueo administrado en lugar del bloqueo no administrado. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, etc. responden todos a Thread.Interrupt y a Thread.Abort. Además, si su subproceso se realiza en un apartamento de un único subproceso, todas estas operaciones de bloqueo administradas suministrarán correctamente mensajes al apartamento mientras que el subproceso está bloqueado.

Vea también

Referencia

Thread.ApartmentState

Threadstate (enumeración)

ServicedComponent

Thread

Monitor