c# - waitcallback - threadpool queueuserworkitem example

Thread.Start() versus ThreadPool.QueueUserWorkItem()

Question

La biblioteca de clases base de Microsoft .NET proporciona varias maneras de crear un hilo y comenzarlo. Básicamente, la invocación es muy similar a cualquier otra proporcionando el mismo tipo de servicio: crea un objeto que representa un flujo de ejecución (o más), le asigna un delegado que representa el flujo de ejecución para ejecutar y, eventualmente, dependiendo de la firma del delegado, un objeto como un parámetro.

Bueno, hay dos enfoques (esencialmente):

1) Usando la clase System.Threading.Thread .

Thread curr = new Thread(myfunction); /* In a class, myfunction is a void taking an object */
curr.Start(new Object()); /* Or something else to be downcast */

2) Usando la clase System.Threading.ThreadPool .

ThreadPool.QueueUserWorkItem(myfunction, new Object()); /* Same philosophy here */

¿Hay alguna razón especial por la que debería usar 1) o 2)? Razones de rendimiento? ¿Patrones? ¿Cuál es el mejor enfoque?

Tengo la sensación de que la respuesta es: "Depende de la situación". ¿Podrían enumerar algunas situaciones en las que un enfoque es mejor que otro?

Answer 1

Al usar ThreadPool, tiene menos control del sistema de subprocesamiento. Esta es una compensación para simplificar el proceso para usted. Si tiene todo lo que necesita de ThreadPool, debe tener la libertad de utilizarlo. Si necesita más control de los hilos, entonces debe usar las clases Thread.

Answer 2

Comenzar un nuevo hilo puede ser una operación muy costosa. El grupo de hilos reutiliza los hilos y, por lo tanto, amortiza el costo. A menos que necesite un hilo dedicado, el conjunto de subprocesos es el camino recomendado. Al usar un hilo dedicado, tiene más control sobre los atributos específicos del hilo, como prioridad, cultura, etc. Además, no debe realizar tareas de ejecución larga en el grupo de subprocesos, ya que obligará al grupo a engendrar subprocesos adicionales.

Además de las opciones que mencionas, .NET 4 ofrece algunas grandes abstracciones para la concurrencia. Consulte las clases Tarea y Paralelo, así como todos los nuevos métodos PLINQ.

Answer 3

En .NET 4.5.2, agregaron un nuevo método: HostingEnvironment.QueueBackgroundWorkItem .

Esto parece ser una alternativa a ThreadPool.QueueUserWorkItem . Ambos se comportan de manera similar, pero hay algunos buenos beneficios al usar el nuevo método cuando se trabaja en ASP.NET:

El método HostingEnvironment.QueueBackgroundWorkItem le permite programar elementos de trabajo de fondo pequeños. ASP.NET realiza un seguimiento de estos elementos y evita que IIS finalice abruptamente el proceso de trabajo hasta que se completen todos los elementos de trabajo en segundo plano. Este método no se puede llamar fuera de un dominio de aplicación administrada de ASP.NET.

Answer 4

Los hilos en ThreadPool son hilos de fondo; Todos los hilos creados e iniciados por un nuevo objeto Thread son hilos de primer plano.

Un hilo de fondo no mantiene el entorno de ejecución gestionada ejecutándose.

consulte http://msdn.microsoft.com/en-us/library/h339syd0.aspx para obtener más información.

Answer 5

ThreadPool.QueueUserWorkItem () es básicamente para situaciones de disparar y olvidar, cuando la aplicación no depende de si las operaciones finalizarán o no.

Use hilos clásicos para un control de grano fino.

Answer 6

Managed Thread Pool tiene algunas pautas muy buenas sobre cuándo NO usar el grupo de subprocesos.

En mi experiencia, quieres crear tu propio hilo cuando necesitas un hilo persistente, dedicado y de larga ejecución. Para todo lo demás, utilice delegados asincrónicos o algo así como QueueUserWorkItem , BackgroundWorker o las funciones relacionadas con la tarea de .NET 4.0.