for - multithreading c# book

Thread/threadpool o backgroundworker

Question

Me gustaría saber qué usar para tareas que requieren mucho rendimiento. Backgroundworker , Thread o ThreadPool ?

He estado trabajando con Threads hasta ahora, pero necesito mejorar la velocidad de mis aplicaciones.

Answer 1

El marco para iniciar tareas intensivas de CPU en subprocesos es irrelevante para su problema, a menos que tenga subtareas de grano excesivamente pequeño.

Necesita dividir su trabajo en subtareas que se pueden ejecutar en paralelo cuando tiene más de una CPU para hacerlo.

Answer 2

Esta elección realmente no importa. BackgroundWorker es un hilo ThreadPool, así que no hay diferencia de todos modos. Sin embargo, podría intentar optimizar el número de subprocesos con ThreadPool.SetMaxThreads.

Y es posible que desee utilizar la clase System.Threading.Task que podría ayudar a optimizar la ejecución en paralelo.

Answer 3

BackgroundWorker es lo mismo que un hilo de grupo de subprocesos. Agrega la capacidad de ejecutar eventos en el hilo de la interfaz de usuario. Muy útil para mostrar el progreso y actualizar la interfaz de usuario con el resultado. Por lo tanto, su uso típico es evitar que la IU se congele cuando se deben realizar trabajos. El rendimiento no es el primer objetivo, el código de ejecución es asíncrono . Este patrón también se extiende hábilmente en versiones .NET posteriores mediante la clase Task <> y las palabras clave async / await.

Los subprocesos del grupo de subprocesos son útiles para evitar consumir recursos. Un hilo es un objeto costoso del sistema operativo y puede crear un número muy limitado de ellos. Un hilo toma 5 identificadores de sistema operativo y un megabyte de espacio de direcciones de memoria virtual. Sin método Dispose () para liberar estos identificadores temprano. El grupo de subprocesos existe principalmente para reutilizar subprocesos y para garantizar que no muchos de ellos estén activos. Es importante que use un hilo de grupo de subprocesos solo cuando el trabajo que realiza sea limitado, lo ideal es que no lleve más de medio segundo. Y no bloqueando a menudo. Por lo tanto, es más adecuado para breves ráfagas de trabajo, no para nada donde el rendimiento importa. El manejo de la finalización de E / S es una tarea ideal para un hilo TP.

Sí, también es posible usar subprocesos para mejorar el rendimiento de un programa. Lo harías usando Thread o Task <> que usa TaskContinuationOptions.LongRunning. Hay algunos requisitos difíciles para obtener una mejora en el rendimiento, son bastante rígidos:

• Necesitas más de un hilo. En un caso ideal, dos hilos pueden necesitar la mitad del tiempo necesario para realizar un trabajo. Y menos, cuantos más hilos usas. Acercarse a ese ideal es sin embargo difícil, no escala infinitamente. Google "Ley de Amdahl" para obtener información.
• Necesita una máquina con un procesador que tenga múltiples núcleos. Es fácil de conseguir en estos días. La cantidad de hilos que cree no debe exceder la cantidad de núcleos disponibles. Usar más generalmente reducirá el rendimiento.
• Necesita el tipo de trabajo vinculado a cómputo, teniendo el motor de ejecución del procesador como el recurso restringido. Eso es bastante común, pero ciertamente no slamdunk. Muchos trabajos están realmente limitados por el rendimiento de E / S, como la lectura de un archivo o la consulta de dbase. O están limitados por la velocidad a la que el procesador puede leer datos de la RAM. Dichos trabajos no se benefician de los hilos, tendrá múltiples motores de ejecución disponibles, pero aún tendrá un solo disco y un bus de memoria.
• Necesita un algoritmo que pueda distribuir el trabajo entre varios hilos sin apenas necesidad de sincronización. Ese suele ser el problema complicado de resolver, muchos algoritmos son de naturaleza muy secuencial y no son fácilmente paralelizables.
• Necesitarás tiempo y paciencia para que el código sea estable y funcione bien. Escribir código enhebrado es difícil y una carrera de subprocesos que bloquea su programa una vez al mes, o produce un resultado no válido de vez en cuando puede ser una gran pérdida de tiempo.