Para ver el artículo en inglés, active la casilla Inglés. También puede ver el texto en inglés en una ventana emergente si pasa el puntero del mouse por el texto.
Traducción
Inglés

Managed and Unmanaged Threading in 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 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 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 los 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.

System_CAPS_noteNota

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, consulte Procesos, subprocesos y contenedores.) La propiedad SIDHistory lo hace posible. Si el estado no se ha establecido, GetApartmentState devuelve ApartmentState.Unknown.

La propiedad solo se puede establecer cuando el estado del subproceso es ThreadState.Unstarted y únicamente 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.

System_CAPS_importantImportante

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 los que se 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, entonces su objeto debe derivarse de ServicedComponent (que a su vez se 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 y demás 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.

Mostrar: