Pregunta de diseño de Threadpool

Question

Tengo una pregunta de diseño. Quiero información para saber si un ThreadPool es apropiado para el programa de cliente que estoy escribiendo.

Tengo un cliente ejecutándose como un servicio que procesa los registros de la base de datos. Cada uno de estos registros contiene información de conexión a sitios FTP externos [básicamente es una cola de archivos para transferir]. Muchos de ellos pertenecen al mismo host, solo mueven archivos diferentes. Por lo tanto, los estoy agrupando por host. Quiero ser capaz de crear un nuevo hilo por host. Realmente no me importa cuándo terminen las transferencias, solo tienen que hacer todo el trabajo (o intentar hacer) que se les asignaron, y luego terminar una vez que hayan terminado, limpiando todos los recursos que usaron en el proceso.

Anticipo que no se establezcan más de 10-25 conexiones. Una vez que la cola de transferencia está vacía, el programa simplemente esperará hasta que haya registros en la cola nuevamente.

¿Es el ThreadPool un buen candidato para esto o debería utilizar un enfoque diferente?

Editar: En su mayor parte, esta es la única aplicación personalizada significativa que se ejecuta en el servidor.

Answer 1

Según lo que ha descrito, parece que el conjunto de subprocesos sería una buena opción.

Problemas:

1. Un hilo de subprocesos no mantendrá su proceso de vida en el apagado. Asegúrate de que ese sea el comportamiento que deseas.

2. En lectura antigua, puede ser malo vincular el grupo de subprocesos con tareas de ejecución prolongada cuando la aplicación podría estar esperando en conexiones incompetentes (como una aplicación web). Sin embargo, parece que tienes un servicio de Windows dedicado, así que no creo que sea un problema.

3. El hecho de que arroje 10 trabajos en el grupo de subprocesos no significa que enviará inmediatamente 10 subprocesos para hacer el trabajo; usted está delegando la decisión de cuántos subprocesos usar para .net y el o/s .

Answer 2

No, el grupo de subprocesos no es apropiado. El grupo de subprocesos está diseñado para "tareas breves que requieren procesamiento en segundo plano", ya que el marco depende de la disponibilidad de subprocesos de grupo de subprocesos y los procesos de larga ejecución pueden agotar el grupo de subprocesos.

Las transferencias de Ftp toman un tiempo relativamente largo (incluso con un tiempo de espera razonable), por lo que no son realmente una buena opción. Usted puede ser capaz de obtener utilizando el grupo de subprocesos, pero también puede encontrarse con errores inexplicables si lo usa. Depende de cuánto utiliza la aplicación las características del marco dependiente del grupo de subprocesos (delegados asíncronos, etc.).

El tema de MSDN "The Managed Thread Pool" ofrece buenas pautas para cuando no de usar hilos de grupo de subprocesos:

Hay varios escenarios en los que es apropiado para crear y gestionar sus propios hilos en lugar de utilizar hilo hilos de grupo:

• Necesita un hilo de primer plano.
• Necesita un hilo para tener una prioridad particular.
• Tiene tareas que hacen que el hilo se bloquee durante largos períodos de tiempo. El grupo de subprocesos tiene un número máximo de subprocesos , por lo que una gran cantidad de subprocesos de agrupación de subprocesos bloqueados pueden impedir el inicio de las tareas .
• Necesita colocar hilos en un apartamento de subproceso único. Todos los hilos ThreadPool se encuentran en el apartamento multiproceso .
• Necesita tener una identidad estable asociada con el hilo, o dedicar un hilo a una tarea.

Answer 3

Un ThreadPool sería bueno ya que le permite concentrarse en la creación de puestos de trabajo en la cola de hilos, en lugar de preocuparse por la inicialización y limpieza de hilos individuales.

Pero, ¿cómo quieres que funcione? ¿Va a poner en cola varios trabajos en el grupo para un host o va a tener un hilo para cada host que lea los trabajos de su propia cola?