Exportar (0) Imprimir
Expandir todo
Este artículo se tradujo de forma manual. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

Subprocesamiento administrado y no administrado en Windows

La administración de todos los subprocesos se realiza mediante la clase Thread, incluidos los subprocesos creados por Common Language Runtime y los creados fuera del runtime 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 entrar en el entorno de ejecución administrado a través de la interoperabilidad COM (porque el runtime expone objetos administrados como objetos COM a 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 runtime ya tiene en cuenta este subproceso. Si no lo encuentra, el runtime compila un nuevo objeto Thread y lo instala en el almacén local de ese subproceso.

En subprocesos administrados, Thread.GetHashCode es la identificación del subproceso administrado estable. En cuanto a la duración de su subproceso, no estará en conflicto con el valor de ningún otro subproceso, independientemente del dominio de la aplicación del que obtiene este valor.

Nota Nota

Un ThreadId de sistema operativo no tiene una relación fija con un subproceso administrado, ya que un host no administrado puede controlar la relación entre subprocesos administrados y no administrados. En concreto, un host sofisticado puede usar la API de fibras para programar muchos subprocesos administrados en el mismo subproceso de sistema operativo o para mover un subproceso administrado entre distintos subprocesos de sistema operativo.

En la tabla siguiente se asignan elementos de subproceso de Win32 a sus equivalentes de runtime aproximados. Tenga en cuenta que esta asignación 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 su código de reversión, recupera todos los recursos y se puede denegar con ResetAbort. Asegúrese de leer detenidamente la documentación y no realice suposiciones sobre 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 identificador de subproceso

Thread.Join

ExitThread

No equivalente

GetCurrentThread

Thread.CurrentThread

SetThreadPriority

Thread.Priority

No equivalente

Thread.Name

No equivalente

Thread.IsBackground

Cercano a CoInitializeEx (OLE32.DLL)

Thread.ApartmentState

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 el artículo sobre procesos, subprocesos y contenedores). Los métodos GetApartmentState, SetApartmentState y TrySetApartmentState de la clase Thread devuelven y asignan el estado de contenedor de un subproceso. Si no se ha establecido el estado, GetApartmentState devuelve ApartmentState.Unknown.

La propiedad solo se puede establecer cuando el estado del subproceso es ThreadState.Unstarted; solo se puede establecer una vez por 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 de finalizador y todos los subprocesos controlados por ThreadPool son MTA.

Nota importante 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. En .NET Framework 1.0 y 1.1, la propiedad ApartmentState se puede establecer como la primera línea de código. Esto no está permitido en .NET Framework 2.0.

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 EnterpriseServices, entonces su objeto debe derivar de ServicedComponent (que a su vez deriva de ContextBoundObject).

Cuando el código administrado llama a objetos COM, siempre sigue 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.

Si un subproceso realiza una llamada no administrada al sistema operativo que ha bloqueado el subproceso en código no administrado, el runtime no tomará el control de él para Thread.Interrupt ni 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. Lo preferible para usted es usar un bloqueo administrado en vez de no administrado. WaitHandle.WaitOne ,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, etc. responden todos a Thread.Interrupt y 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.

Adiciones de comunidad

AGREGAR
Mostrar:
© 2015 Microsoft