¿Es posible cambiar parallelOptions.MaxDegreeOfParallelism durante la ejecución de un Parallel.ForEach

Question

estoy corriendo un multi-hilo de bucle:

protected ParallelOptions parallelOptions = new ParallelOptions(); 

parallelOptions.MaxDegreeOfParallelism = 2; 
Parallel.ForEach(items, parallelOptions, item => 
{ 
// Loop code here 
}); 

Quiero cambiar el parallelOptions.MaxDegreeOfParallelism durante la ejecución del bucle paralelo a reducir o aumentar una cantidad de hilos.

parallelOptions.MaxDegreeOfParallelism = 5; 

No parece aumentar los hilos. ¿Alguien tiene alguna idea?

Answer 1

No esperaba que fuera posible cambiar el grado de paralelismo después de haber llamado al ForEach. Según lo entiendo, ForEach va a determinar cuántos hilos puede crear, crear tantas particiones y crear los hilos para operar en esas particiones. No tiene sentido que pueda decir: "Oh, espera, cambió nuestra asignación de recursos, me permitió volver a particionar la matriz y reasignar hilos".

Answer 2

El problema con incluso tratar de hacer esto es que es un problema difícil. Para empezar, ¿cómo se puede observar la utilización de la CPU y del disco de manera confiable? El muestreo de la CPU con poca frecuencia dará una imagen pobre de lo que realmente está sucediendo y la utilización del disco de muestreo es aún más difícil. En segundo lugar, ¿cuál es la granularidad de sus tareas y con qué frecuencia puede cambiar rápidamente el número que se está ejecutando? En tercer lugar, las cosas cambian rápidamente con el tiempo, por lo que debe aplicar algún tipo de filtrado a sus observaciones. En cuarto lugar, la cantidad ideal de subprocesos dependerá de la CPU en la que se esté ejecutando realmente el código. En quinto lugar, si distribuyes demasiados hilos, estarás luchando entre ellos en lugar de hacer un trabajo útil.

Consulte http://msdn.microsoft.com/en-us/magazine/ff960958.aspx para una discusión sobre cómo el Thread Pool en .NET maneja la compleja tarea de decidir cuántos subprocesos usar.

También podría usar el reflector y observar el código que TPL usa para asignar hilos y evitar el cambio de contexto innecesario: ¡es complejo y ni siquiera tiene acceso a disco en la cuenta!

En su lugar, podría intentar ejecutar las tareas en un subproceso de menor prioridad (crear su propio TaskScheduler que ejecute subprocesos con una prioridad inferior a la normal es bastante fácil). Eso al menos asegurará que pueda ejecutar 100% de CPU sin afectar el resto del sistema. Enredarse con las prioridades de los hilos está lleno de problemas, pero si se trata de una tarea puramente secundaria, puede ser sencillo y puede ser útil.

A menudo, sin embargo, la utilización del disco es el verdadero culpable cuando se trata de otras aplicaciones que sufren a manos de una aplicación codiciosa. Windows puede asignar la CPU de forma justa entre las aplicaciones con facilidad, pero cuando se trata de un acceso de disco relativamente lento, se trata de otra cuestión. En lugar de tratar de ajustar dinámicamente la cantidad de subprocesos que tiene en ejecución, en su lugar puede necesitar limitar su aplicación para que no acceda al disco con demasiada frecuencia. Eso es algo que puede hacer sin cambiar la cantidad de hilos activos.

También puede consultar SetPriorityClass como una forma de informar al sistema operativo que su proceso es menos importante que otras aplicaciones que se ejecutan en el sistema; consulte How can I/O priority of a process be increased? para obtener más información. Pero eso supone que su proceso completo es menos importante, no solo esta parte del mismo.