Estados de subprocesos administrados
Actualización: noviembre 2007
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.
Nota 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, éste se encuentra en el estado Unstarted. El subproceso permanece en el estado Unstarted hasta que el sistema operativo lo cambia al estado iniciado. Si se llama a Start, el sistema operativo puede saber que se puede iniciar el subproceso, pero no cambia su estado.
Los subprocesos no administrados que entran en el entorno administrado ya están en el estado iniciado. Una vez en ese estado, varias acciones pueden ocasionar que el subproceso cambie de 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 |
---|---|
Otro subproceso llama a Thread.Start. |
Unchanged |
El subproceso responde a Thread.Start y empieza a ejecutarse. |
|
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.Suspend. |
|
Otro subproceso llama a Thread.Abort. |
|
El subproceso responde a Thread.Abort. |
Puesto que el estado Runningtiene el valor 0, no es posible realizar una prueba de bits para descubrirlo. 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, éste estará tanto en el estado WaitSleepJoin como en AbortRequested. 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.