.net - library - threadpool java
¿Por qué*no*cambia la prioridad de un subproceso de ThreadPool(o Tarea)? (6)
Ciertamente, puede cambiarlo si realmente lo desea, pero dado que los subprocesos del grupo de subprocesos se reutilizan, el siguiente código que se ejecute podría no esperar el cambio.
Hay muchos lugares en la web y el Desbordamiento de pila en los que no se recomienda cambiar la prioridad de un subproceso de ThreadPool o una tarea TPL. En particular:
"No tiene control sobre el estado y la prioridad de un subproceso de grupo de subprocesos".
"El tiempo de ejecución administra el grupo de subprocesos. No tienes control sobre la programación del subproceso, ni puedes cambiar la prioridad del subproceso".
Sin embargo, es un asunto simple hacerlo, y el depurador muestra que el cambio parece mantenerse (en la medida en que el valor puede leerse).
Thread.CurrentThread.Priority = ThreadPriority.AboveNormal;
Entonces, la pregunta es, ¿cuál es la razón específica de este tabú en particular?
Mi sospecha: hacerlo perturba las delicadas suposiciones de equilibrio de carga de la piscina. Pero esto no explica por qué algunas fuentes dicen que no puedes cambiarlo.
El grupo de subprocesos, especialmente el grupo de subprocesos .NET 4.0, tiene muchos trucos bajo la manga y es un sistema bastante complicado. Agregue tareas y programadores de tareas, robo de trabajo y todo tipo de otras cosas y la realidad es que no sabe lo que está pasando. El grupo de subprocesos puede notar que su tarea está esperando en E / S y decidir programar algo rápido en su tarea o suspender su subproceso para ejecutar algo de mayor prioridad. Su hilo puede ser de alguna manera una dependencia para un hilo de mayor prioridad (que puede o no estar al tanto) y terminar causando un interbloqueo. Su hilo puede morir de alguna manera anormal y ser incapaz de restaurar la prioridad.
Si tiene una tarea de larga duración de tal manera que cree que sería mejor que su hilo tenga una prioridad más baja, entonces el grupo de hilos probablemente no sea para usted. Si bien los algoritmos se han mejorado en .NET 4.0, aún es mejor utilizarlo para tareas de corta duración en las que el costo de crear un nuevo subproceso no es proporcional a la duración de la tarea. Si su tarea se ejecuta durante más de uno o dos segundos, el costo de crear un nuevo subproceso es insignificante (aunque la administración puede ser molesta).
He realizado algunos experimentos con un conjunto de subprocesos de tamaño reducido que parece indicar que la prioridad del subproceso se restablece a la normalidad una vez que se devuelve al conjunto. This recurso en hilos parece confirmarlo. Así que el efecto parece ser muy limitado incluso si lo haces.
No se recomienda, especialmente si aumenta la prioridad, ya que puede afectar el rendimiento general de su sistema.
No ofrecer una respuesta complicada, pero en general, la prioridad de los hilos es un tema complejo. Por ejemplo, Windows tiene 2 descriptores relacionados: prioridad de hilo y prioridad de proceso. Ambos van desde Inactivo, el más bajo, hasta Tiempo crítico, el más alto. Cuando inicia un nuevo proceso, se establece en el valor predeterminado, el rango medio (una prioridad de proceso normal con una prioridad de subproceso normal).
Además, las prioridades de los subprocesos son relativas, lo que significa que incluso establecer la prioridad de un subproceso en la más alta en un sistema ocupado no garantiza que se ejecutará en "tiempo real". DotNET no ofrece ninguna garantía al respecto, ni tampoco Windows. A partir de eso, se puede ver por qué es mejor dejar el subproceso en paz, ya que, el 99.9% del tiempo, sabe mejor :)
Dicho todo esto, está bien reducir la prioridad de un hilo si la tarea implica un cálculo largo. Esto no afectará otros procesos.
Sin embargo, la prioridad creciente solo se debe hacer para las tareas que necesitan reaccionar rápidamente y tienen un tiempo de ejecución corto, ya que esto puede afectar negativamente a otros procesos.
Reducir la prioridad también podría llevar a consecuencias inesperadas.
Imagine que programa una tarea en una aplicación, pero que también llama a una biblioteca que programa otras tareas. Diga que baja la prioridad del hilo mientras se ejecuta la tarea de aplicación. Luego, puede terminar con las tareas de prioridad normal en la biblioteca esperando que esa tarea de baja prioridad termine, si el grupo no genera muchos subprocesos, pero al subproceso de baja prioridad no se le puede dar mucho tiempo de CPU si el resto de El sistema tiene muchos hilos de prioridad normal que quieren ejecutar.
Aumentar el número de subprocesos de agrupación lo aliviaría, a costa de perder más memoria en pilas y gastar más tiempo de CPU en interruptores de contexto.
Si cambia algo, use probar / finalmente para asegurarse de dejarlo como lo encontró.