2010-04-30 11 views

Respuesta

19

todos ellos utilizan hilos internos, las diferencias tienen que ver con el nivel de abstracción de cada API y cómo se utilizan los hilos. Vamos a volver a pedir su lista un poco y mirar las tres técnicas de menor a mayor nivel de abstracción:

  1. Comenzar un nuevo hilo manualmente:

    En realidad, esto crea un nuevo hilo en el sistema operativo . Su código se ejecutará en ese hilo.

  2. El uso de un BackgroundWorker:

    Internamente utiliza algo llamado el .NET ThreadPool. El grupo de subprocesos es básicamente un conjunto de subprocesos disponibles. Su código se asigna a uno de los hilos disponibles y se ejecuta en ese hilo.

    El grupo administra la cantidad de subprocesos disponibles y creará internamente y destruirá subprocesos según se requiera dentro de ciertos límites. Esto es útil porque el grupo puede tener algunos algoritmos para optimizar la creación del hilo. La creación de subprocesos es un proceso bastante costoso, por lo que, si procede, el grupo de subprocesos mantiene los subprocesos activos y los reutiliza para futuras solicitudes. Puede tener un control limitado sobre el grupo al especificar el número mínimo/máximo de subprocesos y algunos ajustes menores como ese.

    Existen otras formas de utilizar ThreadPool directamente, como QueueUserWorkItem(...).

  3. Utilización de la biblioteca de tareas en paralelo:

    Esta es una abstracción aún mayor. Usted crea "tareas" y le dice al TPL que las ejecute. El TPL oculta todas las preocupaciones con respecto a exactamente cuántos hilos y qué prioridades se utilizarán, etc. El TPL tiene la capacidad de reutilizar hilos y gestionarlos de acuerdo con el rendimiento específico de la máquina y los recursos de CPU disponibles.

    Por ejemplo, dado 100 tareas, en un núcleo cuádruple, el TPL podría engendrar 4 hilos, pero en un núcleo 8 podría generar 8 y distribuir las tareas sobre los hilos disponibles a medida que se completa cada tarea.

Así que para responder a su pregunta. Las tres técnicas usan subprocesos, pero a medida que sube cada nivel, se reduce la cantidad de control y conciencia que tiene sobre esos hilos.

En la mayoría de los casos, le recomendaría que use el TPL. A menos que necesites un control preciso específico sobre la cantidad de hilos y su creación/destrucción, TPL lo manejará muy bien.

3
  1. Comenzar un nuevo hilo es el más caro de los tres, pero le brinda más posibilidades. Como establecer el modelo y la prioridad del apartamento.

  2. tareas de la Biblioteca paralelo se ejecutará una tarea en la ThreadPool (a menos que se marca una tarea como la necesidad de su propio hilo) y añade manejo de excepciones y esperar para la finalización funcionalidad.

  3. BackgroundWorker solo es útil para ejecutar tareas generadas desde WinForms o WPF. También utiliza Threadpool

  4. Extra: ThreadPool. Se usa para ejecutar tareas cortas sin la sobrecarga de crear un Tema separado.

+1

+1 for 'ThreadPool' – Cornelius

2

La creación de un hilo es solo eso ... engendras un hilo único para ejecutar al mismo tiempo el hilo de proceso principal.

En TPL, si crea una Tarea, usará un grupo de subprocesos para encontrar un hilo libre para ejecutar la tarea. Esto puede ser más eficiente cuando crea muchas tareas porque TPL puede equilibrar la carga en cualquier cantidad de hilos libres (presumiblemente el número de hilos está equilibrado en función del número de núcleos que tiene, pero no lo sé con certeza.)

Finalmente, un BackgroundWorker ejecuta su trabajo en una secuencia separada. En realidad, es solo una buena abstracción que te saca de las partes complicadas del enhebrado, ya que se maneja para ti. También proporciona una forma de enviar actualizaciones de estado si no me equivoco. (no estoy seguro si esto usa el grupo de subprocesos de Windows, pero no me sorprendería)

Al final, tiene que elegir lo que es correcto para su programa, pero el propósito de las tareas TPL es permitirle programar tareas que se pueden ejecutar en paralelo, mientras que crear hilos o usar trabajadores de fondo puede ser mejor para operaciones de larga ejecución o para escenarios en los que quieres que el hilo de fondo viva esperando por alguna señal (a través de, sugeriría realmente usar RegisteredWait si solo estamos esperando que algún evento indique.)

Cuestiones relacionadas