Cuándo no debo usar ThreadPool in.Net? [cerrado]

@ Eric, voy a tener que estar de acuerdo con Dean. Los hilos son caros. No puede asumir que su programa es el único que se está ejecutando. Cuando todos son codiciosos con los recursos, el problema se multiplica.

Prefiero crear mis hilos manualmente y controlarlos yo mismo. Mantiene el código muy fácil de entender.

Eso está bien cuando es apropiado. Sin embargo, si necesita un montón de hilos de trabajo, todo lo que ha hecho es hacer que su código sea más complicado. Ahora tienes que escribe código para administrarlos. Si solo usaras un grupo de subprocesos, obtendrías toda la administración de subprocesos de forma gratuita. Y el grupo de hilos proporcionado por el lenguaje es muy probable que sea más robusto, más eficiente y menos buggy que lo que sea que ruede por sí mismo.

Thread t = new Thread(new ThreadStart(DoSomething));  
t.Start();  
t.Join();  

Espero que normalmente tengas algún código adicional entre Start() y Join(). De lo contrario, el hilo extra es inútil, y estás desperdiciando recursos sin ninguna razón.

La gente está demasiado asustada de los recursos utilizados por los hilos. Nunca he visto crear e iniciar un hilo que tome más de un milisegundo. No hay límite en el número de hilos que puede crear. El uso de RAM es mínimo. Una vez que tenga unos pocos cientos de subprocesos, la CPU se convierte en un problema debido a los cambios de contexto, por lo que en ese momento es posible que desee obtener fantasía con su diseño.

Un milisegundo es un largo tiempo en hardware moderno. Son 3 millones de ciclos en una máquina de 3 GHz. Y de nuevo, no eres el solo uno creando hilos. Tus subprocesos compiten por la CPU junto con los subprocesos de cualquier otro programa. Si no usas demasiados hilos, y también lo hace otro programa, entonces juntos has usado demasiados hilos.

En serio, no hagas la vida más compleja de lo que necesita ser. No uses el thread pool a menos que necesites algo muy específico que ofrezca.

En efecto. No hagas la vida más compleja. Si su programa necesita varios hilos de trabajo, no reinvente rueda. Usa el grupo de hilos. Por eso está ahí. ¿Harías tu propia clase de cuerdas?

Los grupos de subprocesos tienen sentido siempre que tenga el concepto de subprocesos de trabajo. Cada vez que puede particionar fácilmente el procesamiento en trabajos más pequeños, cada uno de los cuales se puede procesar de forma independiente, los subprocesos de trabajo (y, por lo tanto, un grupo de subprocesos) tienen sentido.

Los grupos de subprocesos no tienen sentido cuando necesita subprocesos que realizan acciones completamente diferentes y no relacionadas, que no pueden considerarse "trabajos"; por ejemplo, un subproceso para el manejo de eventos GUI, otro para el procesamiento de backend. Grupos de hilos también no tiene sentido cuando el procesamiento forma una tubería.

Básicamente, si tiene subprocesos que inician, procesan un trabajo y salen, un grupo de subprocesos es probablemente el camino a seguir. De lo contrario, el grupo de hilos realmente no va a ayudar.

A la respuesta de pendenciero, agregaría que es mejor no usar un hilo ThreadPool si necesita garantizar que su hilo comenzará a funcionar inmediatamente. El número máximo de subprocesos en ejecución agrupados está limitado por appdomain, por lo que es posible que tu trabajo tenga que esperar si todos están ocupados. Se llama "elemento de trabajo de usuario de cola", después de todo.

Dos advertencias, por supuesto:

1. Puede cambiar el número máximo de subprocesos agrupados en el código, en tiempo de ejecución, por lo que no hay nada para que deje de comprobar el número actual vs máximo y subir el máximo si es necesario.
2. Girar un nuevo hilo viene con su propia penalización de tiempo - si vale la pena para que usted tome el golpe depende de sus circunstancias.

No estoy hablando como alguien con solo conocimiento teórico aquí. Escribo y mantener aplicaciones de alto volumen que hacen un uso intensivo de multihilo, y generalmente no encuentro el hilo pool para ser la respuesta correcta.

Ah, argumento de autoridad - pero siempre esté atento a las personas que podrían estar en el equipo del kernel de Windows.

Ninguno de nosotros discutía con el hecho de que si tiene algunos requisitos específicos, entonces el ThreadPool. NET puede que no sea lo correcto. Lo que estamos objetando es la trivialización de los costos para la máquina de crear un hilo.

El gasto significativo de crear un hilo en la razón de ser para el ThreadPool en primer lugar. No quiero que mis máquinas estén llenas de código escrito por personas que han sido mal informadas sobre el costo de crear un hilo, y no saben, por ejemplo, que hace que se llame a un método en cada DLL que está adjunto al proceso (algunos de los cuales serán creados por terceros), y que bien puede calentar una carga de código que no necesita estar en RAM en absoluto y casi seguramente no necesitaba estar en L1.

La forma de la jerarquía de memoria en una máquina moderna significa que 'distraer' a una CPU es lo peor que puede hacer, y todos los que se preocupan por su arte deben trabajar duro para evitarlo.

Cuando vas a realizar una operación que va a tomar mucho tiempo, o tal vez un hilo de fondo continuo. Supongo que siempre podría empujar la cantidad de hilos disponibles en el grupo, pero no tendría mucho sentido incurrir en los costos de gestión de un hilo que nunca se devolverá al grupo.

MSDN tiene una lista de algunas razones aquí:

Http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

Hay varios escenarios en los que es apropiado crear y administre sus propios hilos en lugar de usar hilos de grupo de hilos:

• Necesita un hilo en primer plano.
• Necesita que un hilo tenga una prioridad particular.
• Tiene tareas que hacen que el hilo se bloquee durante largos períodos de tiempo. El grupo de hilos tiene un número máximo de hilos, por lo que una gran el número de subprocesos bloqueados puede impedir que las tareas partida.
• Es necesario colocar los hilos en un apartamento de un solo hilo. Todos los hilos ThreadPool están en el apartamento multihilo.
• Necesita tener una identidad estable asociada con el hilo, o dedicar un hilo a una tarea.

Los subprocesos Threadpool son apropiados para tareas que cumplen los dos criterios siguientes:

1. La tarea no tendrá que pasar un tiempo significativo esperando que algo suceda
2. Cualquier cosa que esté esperando que la tarea termine probablemente estará esperando que muchas tareas terminen, por lo que su prioridad de programación no es propensa a afectar mucho las cosas.

Usar un subproceso threadpool en lugar de crear uno nuevo ahorrará una cantidad de tiempo significativa pero limitada. Si eso el tiempo es significativo en comparación con el tiempo que tomará realizar una tarea, una tarea threadpool es probablemente apropiada. Sin embargo, cuanto mayor sea el tiempo requerido para realizar una tarea, menor será el beneficio de usar el threadpool y mayor será la probabilidad de que la tarea impida la eficiencia del threadpool.

@Eric

@Derek, no estoy exactamente de acuerdo con el escenario que usas como ejemplo. Si no sabe exactamente qué se está ejecutando en su máquina y exactamente cuántos hilos totales, manejadores, tiempo de CPU, RAM, etc., que su aplicación usará bajo una cierta cantidad de carga, está en problemas.

¿Eres el único cliente objetivo para los programas que escribes? Si no, no puedes estar seguro de la mayor parte de eso. Por lo general, no tiene idea cuando escribe un programa si lo hará ejecute de manera efectiva solo, o si se ejecutará en un servidor web que esté siendo golpeado por un ataque DDOS. No puedes saber cuánto tiempo de CPU vas a tener.

Suponiendo que el comportamiento de su programa cambia en función de la entrada, es raro incluso saber exactamente cuánta memoria o tiempo de CPU consumirá su programa. Claro, debería tener una idea bastante buena sobre cómo se comportará su programa, pero la mayoría de los programas nunca se analizan para determinar exactamente cuánta memoria, cuántos manejadores, etc. será usado, porque un análisis completo es caro. Si no estás escribiendo software en tiempo real, la recompensa no vale la pena.

En general, afirmar saber exactamente cómo se comportará su programa es descabellado, y afirmar saber todo sobre la máquina se aproxima ridículamente.

Y para ser honesto, si no sabe exactamente qué método debe usar: subprocesos manuales, grupo de subprocesos, delegados y cómo implementarlo para hacer exactamente lo que su aplicación necesita, está en problema.

No estoy totalmente en desacuerdo, pero realmente no veo cómo eso es relevante. Este sitio está aquí específicamente porque los programadores no siempre tienen todas las respuestas.

Si su aplicación es lo suficientemente compleja como para requerir la limitación del número de subprocesos que utiliza, ¿no es casi siempre va a querer más control del que el marco le da?

No. Si necesito un grupo de hilos, usaré el que se proporciona, a menos y hasta que lo encuentre no es suficiente. No asumiré simplemente que el grupo de subprocesos proporcionado es insuficiente para mis necesidades sin confirmar que sea el caso.

No estoy hablando como alguien con solo conocimiento teórico aquí. Escribo y mantengo aplicaciones de alto volumen que hacen un uso intensivo de multihilo, y generalmente no encuentro que el grupo de subprocesos sea la respuesta correcta.

La mayor parte de mi experiencia profesional ha sido con programas multiprocesamiento y multiprocesamiento. Me a menudo he necesitado rodar mi propia solución también. Eso no significa que el grupo de subprocesos no sea útil, o apropiado en muchos casos. El grupo de subprocesos está diseñado para manejar subprocesos de trabajo. En los casos en que múltiples subprocesos de trabajo son apropiados, el grupo de subprocesos proporcionado debería ser generalmente el primer enfoque.