Estados de subprocesos administrados
La propiedad Thread.ThreadState proporciona una máscara de bits que indica el estado actual del subproceso. Un subproceso está siempre en al menos uno de los estados posibles en la enumeración ThreadState y puede estar en varios estados al mismo tiempo.
Importante |
---|
El estado de los subprocesos sólo es de interés en algunos escenarios de depuración.El código nunca debe utilizar el estado de los subprocesos para sincronizar las actividades de los subprocesos. |
Al crear un subproceso administrado, este se encuentra en el estado ThreadState.Unstarted. El subproceso permanece en estado Unstarted hasta que no se llama al método Thread.Start, que pone el subproceso en estado Running para que el sistema operativo pueda programarlo para su ejecución.
Los subprocesos no administrados que entran en el entorno administrado ya están iniciados. Una vez iniciado un subproceso, varias acciones pueden hacer que cambie su estado. En la tabla siguiente se muestran las acciones que pueden provocar un cambio de estado, junto con el nuevo estado correspondiente.
Acción |
Nuevo estado resultante |
---|---|
Se llama al constructor para la clase Thread. |
|
Otro subproceso llama al método Thread.Start en el nuevo subproceso y la llamada devuelve un valor. |
|
El subproceso llama a Thread.Sleep. |
|
El subproceso llama a Monitor.Wait en otro objeto. |
|
El subproceso llama a Thread.Join en otro subproceso. |
|
Otro subproceso llama a Thread.Suspend. |
|
El subproceso responde a una solicitud Thread.Suspend. |
|
Otro subproceso llama a Thread.Resume. |
|
Otro subproceso llama a Thread.Abort. |
|
El subproceso responde a Thread.Abort. |
Puesto que el estado Running tiene el valor 0, no es posible realizar una prueba de bits para detectarlo. En cambio, se puede utilizar la siguiente prueba (en seudocódigo):
if ((state & (Unstarted | Stopped)) == 0) // implies Running
Muchas veces, los subprocesos están en más de un estado en un momento dado. Por ejemplo, si se bloquea un subproceso en una llamada a Monitor.Wait y otro subproceso llama a Abort en ese mismo subproceso, este estará en los estados WaitSleepJoin y AbortRequested al mismo tiempo. En este caso, tan pronto como el subproceso vuelva de la llamada a Wait o se interrumpa, recibirá la excepción ThreadAbortException.
Una vez que un subproceso deja el estado Unstarted como resultado de una llamada a Start, no puede volver nunca al estado Unstarted. Un subproceso no puede dejar nunca el estado Stopped.
Vea también
Referencia
Otros recursos
Historial de cambios
Fecha |
Historial |
Motivo |
---|---|---|
Mayo de 2011 |
Aclaración adicional de la relación entre el método Thread.Start y el estado Running. |
Comentarios de los clientes. |
Marzo de 2011 |
Aclaración de la relación entre el método Thread.Start y el estado Running. |
Corrección de errores de contenido. |