Tengo una aplicación de adquisición de datos ejecutándose en Windows 7, usando VC2010 en C++. Un hilo es un latido que envía un cambio cada .2 segundos para mantener vivo algún hardware que tiene un tiempo de espera de aproximadamente .9 segundos. Normalmente, la llamada de latido requiere de 10 a 20 ms y el hilo pasa el resto del tiempo durmiendo.¿Puedo establecer la prioridad de un solo subproceso por encima de 15 para un proceso de prioridad normal?
Ocasionalmente, sin embargo, habrá un retraso de 1-2 segundos y el hardware se apagará momentáneamente. El hilo del latido se está ejecutando en THREAD_PRIORITY_TIME_CRITICAL que es 15 para un proceso de prioridad normal. Mis otros hilos se ejecutan con la prioridad normal, aunque utilizo una DLL para controlar otro hardware y he notado con Process Explorer que comienza varios subprocesos en el nivel 15.
No puedo rastrear la fuente de la lenta hacia abajo, pero otros temas en mi aplicación están viendo el mismo tipo de retrasos cuando esto sucede. He hecho varias optimizaciones para el código de latido aunque es bastante simple, pero las fallas ocasionales todavía están sucediendo. Ahora me pregunto si puedo aumentar la prioridad de este hilo más allá de 15 sin especificar REALTIME_PRIORITY_CLASS para todo el proceso. Si no, ¿hay alguna desventaja que deba tener en cuenta al usar REALTIME_PRIORITY_CLASS? (Aparte de este hilo latido, el resto de la aplicación no necesita tiempo en tiempo real).
(¿O alguien tiene alguna idea sobre cómo rastrear estas ralentizaciones ... no estoy seguro si la fuente podría estar en mi aplicación o en otro lugar en el sistema).
Actualización: Así que no había intentado pasar 31 en mi llamada AfxBeginThread y resulta que ignora ese valor y establece el hilo a la prioridad normal en lugar de los 15 que obtengo con THREAD_PRIORITY_TIME_CRITICAL.
Actualización: Resulta que la ejecución del Desfragmentador de disco es una buena forma de provocar muchos retrasos en el hilo. Incluso ejecutar el proceso en REALTIME_PRIORITY_CLASS y el hilo del latido en THREAD_PRIORITY_TIME_CRITICAL (nivel 31) no parece ayudar. Lo siguiente que debe intentar es llamar a AvSetMmThreadCharacteristics ("Pro Audio")
Actualización: Programar el hilo del latido como "Pro Audio" funciona para aumentar la prioridad del hilo más allá de 15 (Base = 1, Dinámico = 24) pero no parece hacer una diferencia real cuando se está ejecutando desfragmentación. Pude correlacionar muchas de las ralentizaciones con el desfragmentador de disco, así que apagué el escaneo semanal. Todavía no podemos explicar algunas demoras, así que vamos a aumentar a un tiempo de espera de 5-10 segundos.
Me asusta cuando la gente usa palabras como "latido" y "cerrado por razones de seguridad" en una cuestión de programación acerca de Windows . :) Ciertamente no es un RTOS: http://en.wikipedia.org/wiki/Real-time_operating_system – HostileFork
Creo que su perro guardián es estricto. En un RTOS 500ms son muchos, pero en Windows cualquier cosa por debajo de 15 segundos es arriesgado. Si tienes control sobre tu perro guardián, te sugiero alargar el tiempo de espera o cerrarlo solo si falla un cierto número de tus desencadenantes. – Fozi
Pregunta: ¿Cuál es el tiempo después del cual su hardware se apagará? – Fozi