BackgroundWorker and Threads

Question

¿Cuáles son los pros y los contras en el uso de cualquiera de los dos para lograr una tarea determinada.

La pregunta del millón es ¿cuál usar y cuándo?

Muchas gracias.

Answer 1

Utilizo para asociar a BackgroundWorker como un contenedor de lo que Threads haría. Así que uso BackgroundWorker en trabajos de GUI, y subprocesos en trabajos más especializados o sucios (servicios de Windows, etc.)

Answer 2

Si con "Threads" quiere decir utilizar explícitamente la clase System.Threading.Thread para crear, configurar y ejecutar sus propios hilos, la respuesta es que hacer esto es más trabajo de su parte, implica más ciclos de CPU que simplemente sacando un hilo del grupo de subprocesos, (que es lo que hacen las otras técnicas), pero le da más flexibilidad, ya que le permite especificar la prioridad de subprocesos y muchas otras características que no le son posibles utilizando subprocesos de subprocesos.

El enfoque "Grupo de subprocesos" es más apropiado cuando no se conoce el número de subprocesos requeridos en el momento del diseño. El grupo contiene inicialmente un pequeño número de subprocesos, "listo" para que los invoque. Puede crear dinámicamente nuevos subprocesos a pedido y gestiona la creación, coordinación y eliminación de subprocesos no utilizados por usted. Hay tres mecanismos que puede usar para acceder y usar subprocesos del grupo.

1. Usando Delegate.BeginInvoke() (la técnica más común)
2. Usando temporizadores (varias variaciones)
3. System.Threading.ThreadPool ofrece varias otras características (clase BackgroundWorker, QueueUserWorkItem(), etc.) .

Answer 3

Enlaza solamente cuando no tienes que trabajar con una UI (WinForms o WPF) y trabajadores en segundo plano cuando lo haces tiene que lidiar con una IU.

Se evita un lote de problemas con las IU y los trabajadores en segundo plano.

Answer 4

La clase BackgroundWorker es una manera fácil de agregar un subproceso a un formulario para realizar algunas operaciones pesadas sin bloquear la interfaz de usuario. Usted podría hacer lo mismo con un hilo, pero con un poco más de codificación.

Answer 5

Tenga una mirada en this great threading overview:

[El BackgroundWorker] proporciona las siguientes características:

• A "Cancelar" bandera para señalización de un trabajador a fin sin el uso de Abortar

• Un protocolo estándar para informar el progreso, finalización y cancelación

• Una implementación de IComponent lo que le permite estar situado en el diseñador de Visual Studio manipulación en el subproceso de trabajo

• La capacidad de actualizar Windows Forms y WPF controla en respuesta al progreso del trabajador o de la finalización de excepción.

Las dos últimas características son particularmente útiles - esto significa que usted no tiene que incluir un bloque try/catch en su método de trabajo, y puede actualizar Windows Forms y WPF controles sin necesidad de llamar Control.Invoke.

Answer 6

La clase BackgroundWorker simplemente proporciona eventos que se cambian al contexto de la cadena de interfaz de usuario para usted, pero no se confunda; el evento DoWork (que es donde realmente, bueno, haz el trabajo) todavía se ejecuta en el contexto de otro hilo (como ese es el punto) y al realizar cualquier tipo de interacción con la interfaz de usuario o actualizar, lanzará una excepción en lo mejor, y chocar en el peor. El BackgroundWorker debe usarse en formularios cuando intenta hacer algo que requiere una actualización de UI y cuyo alcance no se extiende más allá del formulario. Para otras operaciones en segundo plano, considere usar el ThreadPool (para operaciones breves) o crear su propio Thread.

BackgroundWorker proporciona comodidad con el evento ProgressChanged, pero no se sienta demasiado cómodo y comience a realizar actualizaciones de IU en DoWork.