2009-06-17 14 views

Respuesta

13

Creo que originalmente no se proporcionó esta información porque cualquier API que proporcionara esta información sería engañosa e inútil.

Considere dos posibles casos: el hilo actual ha suspendido el hilo de interés. Código en el hilo actual sabe sobre el estado suspendido y debería poder compartirlo así que no hay necesidad de que el equipo kernel agregue una API.

El segundo caso, algún otro/un tercer hilo en el sistema ha suspendido el hilo de interés (y no hay manera de rastrear qué hilo fue). Ahora que tiene una condición de carrera, ese otro hilo podría, en cualquier momento, reactivar el hilo de interés y la información recopilada de la API es inútil; tiene un valor que indica que el hilo se suspende cuando, de hecho, no.

Moraleja de la historia: si desea saber que un hilo está suspendido, suspenderlo: el valor de retorno de SuspendThread es el conteo de suspensión anterior del hilo. Y ahora SÍ sabes algo útil: el hilo ESTABA Y SIGUE SI suspendido, lo cual es útil. O que NO FUE (pero ahora está) suspendido. De cualquier manera, el estado del hilo se conoce ahora de manera determinista, por lo que, en teoría, puede tomar algunas decisiones inteligentes basadas en eso, ya sea para reanudar el hilo o mantenerlo suspendido.

+1

Sí, cualquier intento de consultar el estado de suspensión de hilo va a ser intrínsecamente atrevido –

+7

Hay estados de hilos más allá de "suspendido" y "en ejecución". Creo que es más probable que el OP esté interesado en saber qué hilos están bloqueados. En cualquier caso, su punto sobre las condiciones de carrera es bueno. Si hay una forma de obtener el estado de un hilo, debe usarse solo con fines informativos. Cualquier intento de usarlo para controlar el flujo conducirá a un mundo de dolor. –

+0

Exactamente - suspendido o no suspendido no suele ser de interés. Ejecutar o esperar en una señal de sincronización ... eso es lo que suele interesarle, y es claramente algo que puede determinarse ya que los depuradores y las herramientas como el Monitor de rendimiento cubren precisamente esta información. Además, en una aplicación debidamente escrita, los hilos * nunca * se suspenderán a menos que se ejecuten bajo un depurador. – Deltics

0

Usted no lo hace, por desgracia. Dependiendo de su código, podría aproximar esto (estableciendo un indicador cada vez que espere un objeto kernel, por ejemplo), pero tenga en cuenta que un hilo siempre podría bloquear dentro de un sistema operativo o una llamada a la biblioteca y usted no lo sabría.

1

En Windows 7, puede usar QueryUmsThreadInformation. (UMS significa programación en modo usuario).

Ver here para UmsThreadIsSuspended.

+2

Requisito mínimo del cliente: Windows 7 (solo 64 bits) –

+0

Para Windows 7 anterior, me pregunto qué devuelve SuspendThread para un hilo ya suspendido. Tal vez pueda verificarlo de esta forma suspendiendo/reanudando temporalmente y verificando los valores devueltos. Solo una idea, podría no funcionar. –

2

La clase Win32_Thread de WMI tiene una propiedad ThreadState, donde 5: "Suspendido bloqueado" y 6: Suspendido listo.

Necesitará el Id. Del subproceso para obtener directamente la instancia correcta (la propiedad Aspecto del objeto WMI es la id del subproceso).

EDIT: Dada esta consulta PowerShell:

gwmi win32_thread | group ThreadState 

da

 
Count Name Group 
----- ---- ----- 
    6 2  {, , , ...} 
    966 5  {, , , ...} 

WMI tiene una definición diferente de "suspendido" a Win32.

1

usted podría conseguir hilo de suspensión cuenta con un código como éste:

DWORD GetThreadSuspendCount(HANDLE hThread) { 
    DWORD dwSuspendCount = SuspendThread(hThread); 
    ResumeThread(hThread); 
    return dwSuspendCount; 
} 

pero, como ya se ha dicho - que no es exacto. Además, suspender un hilo es malo.

+2

¡Una muy mala idea suspender un hilo solo para obtener su estado! ¿Qué rendimiento tendrá si el hilo está muy ocupado? – Elmue

0

Creo que el estado que aquí se conoce como

  • Si el hilo está en proc hilo, haciendo algún tipo de procesamiento o
  • Esperar evento

Esto puede ser atendido mediante el uso de variable que puede decir si un hilo está realmente ejecutándose o esperando que ocurra un evento.

Estos escenarios aparecen cuando se consideran grupos de subprocesos, tienen algunos n subprocesos y en función de cada estado de ejecución de subproceso, las tareas se pueden asignar a subprocesos inactivos.

3

Puede obtener esta información llamando a NtQuerySystemInformation() con el valor de SystemProcessesAndThreadsInformation (valor entero 5).

Si quiere un ejemplo de lo que puede hacer con esta información, eche un vistazo a Thread Status Monitor.

+0

Esta respuesta es correcta, pero falta el código. No es fácil usar esta API. Publiqué una clase trabajadora aquí: http://stackoverflow.com/questions/22949725/how-to-get-thread-state-eg-suspended-memory-cpu-usage-start-time-priori – Elmue

2

Aunque no está documentado, aunque debe ser en mi humilde opinión, si llama a WaitForSingleObject, devolverá WAIT_ABANDONED si el hilo está suspendido. Además, si un hilo ha terminado, su mango estará en un estado señalizado.

Lo que me molesta más es cuando alguien responde a sus preguntas diciéndole por qué no debe tener una respuesta a su pregunta ... O comienza a cuestionar POR QUÉ desea hacerlo. Cuando alguien encuentra esta pregunta en google, las razones de POR QUÉ no son las mismas y, por lo tanto, la respuesta se dejaría sin efecto para nadie más.

+0

Recién probado y no hay tal cosa. Devuelve 'WAIT_TIMEOUT' tanto en modo ejecutado como suspendido. – CodeAngry

Cuestiones relacionadas