Pregunta

Cuando debo no utilice el ThreadPool en .Neta?

Parece que la mejor opción es utilizar un ThreadPool, en cuyo caso, ¿por qué no es la única opción?

¿Cuáles son sus experiencias en torno a esto?

¿Fue útil?

Solución

La única razón por la que yo no uso el ThreadPool para hoteles de multithreading es si necesito...

  1. interract con el método de ejecución (por ejemplo, para matarlo)
  2. ejecutar código en un Subproceso STA (esto me pasó a mí)
  3. mantener el hilo vivo después de mi solicitud ha muerto (ThreadPool subprocesos subprocesos en segundo plano)
  4. en caso de que sea necesario cambiar la prioridad de un Hilo.No podemos cambiar la prioridad de los hilos en ThreadPool predeterminado es Normal.

P. S.: El artículo de MSDN "El Grupo De Subprocesos Administrados" contiene una sección titulada, "Cuando No Utilizar subprocesos del grupo de Subprocesos", con una muy similar, pero ligeramente más completa lista de posibles razones para no usar el hilo de la piscina.

Hay un montón de razones por qué usted necesita para saltar la ThreadPool, pero si usted no los conoce, a continuación, el ThreadPool debe ser lo suficientemente bueno para usted.

Como alternativa, busque en la nueva Extensiones Paralelas Marco, que tiene algunas cosas ordenadas en que puedan satisfacer sus necesidades sin tener que usar el ThreadPool.

Otros consejos

@Eric, me voy a tener que estar de acuerdo con el Decano.Los hilos son caros.No se puede asumir que su programa es el único en ejecución.Cuando todo el mundo es codicioso, con los recursos, el problema se multiplica.

Yo prefiero crear mis hilos manualmente y control de mí mismo.Se mantiene el código muy fácil de entender.

Eso está bien cuando es apropiado.Si usted necesita un montón de subprocesos de trabajo, sin embargo, todo lo que he hecho es hacer el código más complicado.Ahora usted tendrá que escribir código para su gestión.Si sólo se utiliza un hilo de la piscina, usted recibe todo el subproceso de gestión de forma gratuita.Y el grupo de subprocesos que proporciona el lenguaje es muy probable que sean más robustos, más eficiente y menos buggy que lo sacas de ti mismo.

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

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

Las personas son demasiado miedo de los recursos utilizados por los hilos.Nunca he visto a la creación y a partir de un hilo a tomar más de una milésima de segundo.No hay un límite en el número de subprocesos que se pueden crear.El uso de la RAM es mínima.Una vez que usted tiene un par de cientos de hilos, de la CPU se convierte en un problema debido a los cambios de contexto, por lo que en ese momento es posible que desee obtener de lujo con su diseño.

Un milisegundo es una largo el tiempo en hardware moderno.Que de 3 millones de ciclos en un 3GHz de la máquina.Y de nuevo, no eres el único en la creación de hilos.Los hilos de competir por la CPU junto con todos los otros subprocesos del programa.Si el uso no-muy-demasiado-muchos hilos, y así lo hace otro programa, entonces juntos he usado demasiados hilos.

En serio, no te hacen la vida más compleja de lo que debe ser.No use el hilo de la piscina a menos que necesite algo muy específico que se ofrece.

De hecho.No hacen la vida más complejas.Si su programa de necesidades múltiples subprocesos de trabajo, no reinventar la rueda.Use el hilo de la piscina.Es por eso que está ahí.Iba a rodar su propia clase string?

Hilo de piscinas sentido cuando se tiene el concepto de subprocesos de trabajo.En cualquier momento usted puede fácilmente partición de procesamiento en trabajos más pequeños, cada uno de los cuales se pueden procesar de forma independiente, los subprocesos de trabajo (y, por tanto, un grupo de subprocesos) tienen sentido.

Hilo de piscinas no tienen sentido cuando se necesita hilo que realizar completamente diferentes y no relacionados de acciones, que no puede ser considerado "puestos de trabajo";por ejemplo, el hilo de Una GUI de manejo de eventos, otra para el procesamiento de servidor.Hilo de piscinas también, no tiene sentido cuando el procesamiento de los formularios de una tubería.

Básicamente, si usted tiene hilos de inicio, proceso de trabajo, y el dejar de fumar, un grupo de subprocesos es probablemente el camino a seguir.De lo contrario, el hilo de la piscina no es realmente va a ayudar.

A pendenciero la respuesta, me gustaría añadir que es mejor no usar un ThreadPool hilo si usted necesita para garantizar que el hilo va a empezar a trabajar de inmediato.El número máximo de ejecución de hilo agrupadas de hilos está limitado por el dominio de aplicación, por lo que su pieza de trabajo puede tener que esperar, si todos están ocupados.Se llama "cola de usuario elemento de trabajo", después de todo.

Dos salvedades, por supuesto:

  1. Usted puede cambiar el número máximo de subprocesos agrupado los hilos en el código, en tiempo de ejecución, así que no hay nada para detener la comprobación de la actual vs número máximo y que se aumente al máximo, si es necesario.
  2. Girando un nuevo hilo viene con su propio penalización de tiempo - si es que vale la pena para que usted tome el éxito depende de sus circunstancias.

Yo no estoy hablando como alguien que solo el conocimiento teórico aquí.Escribo y mantener aplicaciones de gran volumen que hacen un uso intensivo de multithreading, y yo por lo general no encontrar el hilo piscina de ser la respuesta correcta.

Ah, el argumento de autoridad -, pero siempre en la mirada hacia fuera para las personas que podrían estar en el núcleo de Windows del equipo.

Ninguno de nosotros estábamos discutiendo con el hecho de que si usted tiene algunos requisitos específicos, a continuación, el .NET ThreadPool podría no ser lo correcto.Lo que estamos objetando es la trivialización de los costos para la máquina de la creación de un hilo.

La significativa el costo de crear un hilo en la razón de ser de la ThreadPool en el primer lugar.No quiero que mis máquinas para ser llenado con el código escrito por personas que han sido mal informados acerca de los costos de la creación de un hilo, y no, por ejemplo, se sabe que provoca un método que se llama en cada archivo DLL que se adjunta a los procesos (algunos de los cuales serán creados por el 3er partes), y que pueden bien caliente hasta una carga de código que no necesitan estar en la memoria RAM en todos y casi seguro que no sería necesario en la L1.

La forma de la jerarquía de memoria en una moderna máquina implica que la 'distracción' una CPU que es lo peor que podés hacer, y todo el mundo que se preocupa acerca de su oficio debe trabajar duro para evitarlo.

Cuando usted va a realizar una operación que se va a tomar un tiempo largo, o tal vez un fondo continuo de hilo.Supongo que siempre se puede empujar a la cantidad de hilos disponible en la piscina, pero habría muy poco en incurrir en los costes de gestión de un hilo que nunca se va a dar vuelta a la piscina.

MSDN tiene una lista de algunas de las razones aquí:

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

Hay varios escenarios en los que es adecuado para crear y administrar sus propios subprocesos en lugar de utilizar subprocesos del grupo de subprocesos:

  • Necesita un subproceso de primer plano.
  • Necesita un hilo que tenga una prioridad determinada.
  • Hay tareas que hacen que el hilo se bloquee durante largos períodos de tiempo.El hilo de la piscina tiene un número máximo de subprocesos, por lo que una gran número de intentos de subprocesos del grupo de subprocesos podría evitar que las tareas de de partida.
  • Es necesario colocar los hilos en un apartamento de un único subproceso.Todos los subprocesos ThreadPool están en el apartamento multiproceso.
  • Usted necesita tener una identidad estable asociados con el hilo, o dedicar un hilo a una tarea.

Threadpool hilos son apropiadas para las tareas que cumplen los siguientes criterios:

  1. La tarea no tendrá que pasar algún tiempo significativo a la espera de que algo suceda
  2. Cualquier cosa que se espera de la tarea de terminar es probable que se espera para muchas tareas para terminar, por lo que su prioridad de programación no apta para afectar mucho las cosas.

El uso de un threadpool hilo en lugar de crear uno nuevo va a ahorrar un importante pero limitada cantidad de tiempo.Si ese tiempo es significativo comparado con el tiempo que se necesita para realizar una tarea, un threadpool tarea es probable que sea apropiado.El más largo es el tiempo requerido para realizar una tarea, sin embargo, el más pequeño es el beneficio de utilizar el threadpool y mayor es la probabilidad de que la tarea de impedir threadpool eficiencia.

@Eric

@Derek, no sé exactamente de acuerdo con el escenario que se utiliza como un ejemplo.Si usted no sabe exactamente lo que se está ejecutando en su máquina y exactamente cuál es el total de los hilos, los mangos, el tiempo de CPU, RAM, etc, por lo que su aplicación va a utilizar en una determinada cantidad de carga, que está en problemas.

Eres el único cliente de la blanco para los programas de escribir?Si no, usted no puede estar seguro acerca de la mayoría de los que.En general, usted no tiene idea de cuando se escribe un programa, ya sea que se va a ejecutar con eficacia en solitario, o si se ejecuta en un servidor web está siendo golpeado por un ataque DDOS.Usted no puede saber cuánto tiempo de CPU que usted va a tener.

Suponiendo que su programa de cambios de comportamiento basado en la entrada, es raro incluso saber exactamente cuánta memoria o el tiempo de CPU que su programa va a consumir.Seguro, usted debe tener una buena idea acerca de cómo el programa va a comportarse, pero la mayoría de los programas nunca son analizados para determinar exactamente cuánta memoria, ¿cuántos mangos, etc.va a ser utilizada, debido a que un análisis completo es caro.Si usted no está escrito en tiempo real de software, la rentabilidad no vale la pena el esfuerzo.

En general, reclamando para saber exactamente cómo el programa se comportará es exagerado, y afirmando conocer todo acerca de la máquina enfoques ridículo.

Y para ser honesto, si usted no sabe exactamente lo que es el método que debe utilizar:manual de subprocesos del grupo de subprocesos, los delegados, y cómo implementar para hacer precisamente lo que necesita la aplicación, usted está en problemas.

No estoy totalmente de acuerdo, pero no veo la forma en que lo relevante.Este sitio está aquí específicamente porque los programadores no siempre tenemos todas las respuestas.

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

No.Si necesito una piscina hilo, voy a utilizar uno de los que siempre, a menos que, y hasta me parece que no es suficiente.Yo simplemente no va a suponer que el hilo de la piscina no es suficiente para mis necesidades sin confirmar que sea el caso.

Yo no estoy hablando como alguien con sólo el conocimiento teórico de aquí.Yo escribo y mantener el alto volumen de aplicaciones que hacen un uso intensivo de subprocesamiento múltiple, y por lo general no es encontrar el hilo de la piscina para ser la respuesta correcta.

La mayor parte de mi experiencia profesional ha sido con el multithreading y multiprocesamiento programas.Tengo a menudo necesaria para rodar mi propia solución.Eso no quiere decir que el hilo de la piscina no es útil o adecuado en muchos casos.El hilo de la piscina está construida para manejar los subprocesos de trabajo.En casos donde varios subprocesos de trabajo son las adecuadas, el grupo de subprocesos deben generalmente ser el primer enfoque.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top