En .NET, ¿hay un programador de subprocesos para subprocesos de larga ejecución?

Question

Nuestro escenario es un escáner de red.

Se conecta a un conjunto de hosts y los escanea en paralelo durante un tiempo utilizando subprocesos de fondo de baja prioridad.

Quiero poder programar un montón de trabajo pero solo tengo un número de diez o cualquier cantidad de hosts analizados en paralelo. Incluso si creo mis propios hilos, las muchas devoluciones de llamada y otras bondades asincrónicas utilizan el ThreadPool y termino quedándome sin recursos. Debería mirar MonoTorrent ...

Si uso THE ThreadPool, ¿puedo limitar mi aplicación a algún número que dejará suficiente para que el resto de la aplicación funcione sin problemas?

¿Hay un subproceso de subprocesos que puedo inicializar a n subprocesos de larga duración?

[Editar] Nadie parece haber notado que hice algunos comentarios sobre algunas respuestas, así que añadiré un par de cosas aquí.

• Las discusiones deben ser cancelables tanto con gracia y fuerza.
• Los subprocesos deben tener baja prioridad dejando la GUI en buen estado.
• Los subprocesos son de larga ejecución pero en orden (minutos) y no en orden (días).

trabajo para un host de destino dado es básicamente:

For each test 
    Probe target (work is done mostly on the target end of an SSH connection) 
    Compare probe result to expected result (work is done on engine machine) 
    Prepare results for host 

¿Puede alguien explicar por qué utilizar la utilidad negativa SmartThreadPool está marcado ingenio ha?

Answer 1

En .NET 4 tiene el Task Parallel Library integrado. Cuando crea una nueva Tarea (la nueva abstracción de hilo) puede especificar que una Tarea sea de larga ejecución. Hemos hecho buenas experiencias con eso (días largos en lugar de minutos u horas).

Puede usarlo también en .NET 2, pero en realidad es una extensión, marque here.

En VS2010 los depuración de aplicaciones paralelas basados ​​en tareas (hilos) no ha sido mejorado radicalmente . Se recomienda usar Tareas siempre que sea posible en lugar de hilos crudos. Ya que le permite manejar el paralelismo de una manera más orientada a objetos.

ACTUALIZACIÓN
tareas que no están especificados como carreras de larga , se ponen en cola en el grupo de subprocesos (o cualquier otro programador para el caso).
Pero si se especifica una tarea para ser carreras de larga, sólo se crea un hilo independiente , ningún grupo de subprocesos está involucrado.

Answer 2

CLR ThreadPool no es apropiado para la ejecución de tareas de larga ejecución: es para realizar tareas breves donde el costo de crear un hilo sería casi tan alto como la ejecución del método en sí. (O al menos un porcentaje significativo del tiempo que se tarda en ejecutar el método.) Como ya has visto, .NET en sí mismo consume subprocesos de grupo de subprocesos, no puedes reservarlos por ti mismo para que no te arriesgues a perder el tiempo de ejecución.

El trabajo de programación, aceleración y cancelación es un asunto diferente. No hay otro grupo de subprocesos de cola de trabajo .NET integrado, por lo que tendrá que rodar por sí mismo (administrando el threads o BackgroundWorkers) o buscar uno preexistente (Ami Bar's SmartThreadPool parece prometedor, aunque yo no lo he usado).

Answer 3

Utilice el grupo de subprocesos integrado. Tiene buenas capacidades.

Como alternativa, puede mirar Smart Thread Pool implementation here o Extended Thread Pool para obtener un límite en el número máximo de hilos de trabajo.

Answer 4

En su caso particular, la mejor opción no serían los subprocesos o el grupo de subprocesos o el trabajador de fondo, sino el modelo de programación asincrónico (BeginXXX, EndXXX) proporcionado por el marco.

Las ventajas de usar el asynchronous model es que la pila TcpIp utiliza devoluciones de llamada cuando hay datos para leer y la devolución de llamada se ejecuta automáticamente en un hilo del grupo de subprocesos.

Usando el asynchronous model, puede controlar el número de solicitudes por intervalo de tiempo iniciado y también puede iniciar todas las solicitudes de un hilo de menor prioridad mientras procesa las solicitudes en un subproceso de prioridad normal lo que significa que los paquetes se mantendrán lo menos posible en la Cola Tcp interna de la pila de red.

Asynchronous Client Socket Example - MSDN

P. S. Para múltiples trabajos simultáneos y de larga ejecución que no hacen gran cantidad de cálculos, pero sobre todo esperan en IO (red, disco, etc.) la mejor opción siempre es usar un mecanismo de devolución de llamada y no hilos.

Answer 5

Crearía su propio administrador de hilos. En el siguiente ejemplo simple, se utiliza una cola para contener hilos en espera y se utiliza un diccionario para contener hilos activos, codificados por ManagedThreadId. Cuando termina un hilo, se elimina del diccionario activo y lanza otro hilo a través de una devolución de llamada.

Puede cambiar el límite máximo de ejecución de subprocesos de su UI y puede pasar información adicional a la devolución de llamada ThreadDone para supervisar el rendimiento, etc. Si un subproceso falla, por ejemplo, un tiempo de espera de red, puede volver a insertar en la cola . Añadir métodos de control adicionales al supervisor para hacer una pausa, detener, etc.

using System; 
using System.Collections.Generic; 
using System.Threading; 

namespace ConsoleApplication1 
{ 
    public delegate void CallbackDelegate(int idArg); 

    class Program 
    { 
     static void Main(string[] args) 
     { 
      new Supervisor().Run(); 
      Console.WriteLine("Done"); 
      Console.ReadKey(); 
     } 
    } 

    class Supervisor 
    { 
     Queue<System.Threading.Thread> waitingThreads = new Queue<System.Threading.Thread>(); 
     Dictionary<int, System.Threading.Thread> activeThreads = new Dictionary<int, System.Threading.Thread>(); 
     int maxRunningThreads = 10; 
     object locker = new object(); 
     volatile bool done; 

     public void Run() 
     { 
      // queue up some threads 
      for (int i = 0; i < 50; i++) 
      { 
       Thread newThread = new Thread(new Worker(ThreadDone).DoWork); 
       newThread.IsBackground = true; 
       waitingThreads.Enqueue(newThread); 
      } 
      LaunchWaitingThreads(); 
      while (!done) Thread.Sleep(200); 
     } 

     // keep starting waiting threads until we max out 
     void LaunchWaitingThreads() 
     { 
      lock (locker) 
      { 
       while ((activeThreads.Count < maxRunningThreads) && (waitingThreads.Count > 0)) 
       { 
        Thread nextThread = waitingThreads.Dequeue(); 
        activeThreads.Add(nextThread.ManagedThreadId, nextThread); 
        nextThread.Start(); 
        Console.WriteLine("Thread " + nextThread.ManagedThreadId.ToString() + " launched"); 
       } 
       done = (activeThreads.Count == 0) && (waitingThreads.Count == 0); 
      } 
     } 

     // this is called by each thread when it's done 
     void ThreadDone(int threadIdArg) 
     { 
      lock (locker) 
      { 
       // remove thread from active pool 
       activeThreads.Remove(threadIdArg); 
      } 
      Console.WriteLine("Thread " + threadIdArg.ToString() + " finished"); 
      LaunchWaitingThreads(); // this could instead be put in the wait loop at the end of Run() 
     } 
    } 

    class Worker 
    { 
     CallbackDelegate callback; 
     public Worker(CallbackDelegate callbackArg) 
     { 
      callback = callbackArg; 
     } 

     public void DoWork() 
     { 
      System.Threading.Thread.Sleep(new Random().Next(100, 1000)); 
      callback(System.Threading.Thread.CurrentThread.ManagedThreadId); 
     } 
    } 
}