Diferencia entre tarea (System.Threading.Task) y subproceso

Question

Según lo que entiendo acerca de la diferencia entre la tarea & El subproceso es que la tarea se realizó en el grupo de subprocesos mientras que el subproceso es algo que necesito administrar yo mismo .. (y esa tarea puede cancelarse y regresar al grupo de hilos al final de su misión)

Pero en algún blog leí que si el sistema operativo necesita crear tareas y crear hilo => será más fácil crear (y destruir) tarea.

Alguien puede explicar por qué la tarea de creación es simple ese hilo?

(o tal vez me falta algo aquí ...)

Answer 1

Yo creo que lo que está hablando cuando dice tareas es una System.Threading.Task. Si ese es el caso, entonces puede pensarlo de esta manera:

• Un programa puede tener muchos hilos, pero un núcleo de procesador solo puede ejecutar un hilo a la vez.
  • hilos son muy caro, y la conmutación entre los subprocesos que se ejecutan también es muy caro.
  • Entonces ... Tener miles de hilos haciendo cosas es ineficiente. Imagine si su maestro le dio 10,000 tareas para hacer. Pasarías tanto tiempo en bicicleta entre ellos que nunca harías nada. Lo mismo le puede pasar a la CPU si comienza demasiados hilos.

Para evitar esto, el marco .NET le permite crear tareas. Las tareas son un poco trabajo incluido en un objeto, y le permiten hacer cosas interesantes como capturar el resultado de ese trabajo y encadenar piezas de trabajo juntas (primero ir a la tienda, luego comprar una revista).

Las tareas se programan en un grupo de subprocesos.El número específico de subprocesos depende del planificador utilizado, pero el planificador predeterminado intenta seleccionar una cantidad de subprocesos que es óptima para la cantidad de núcleos de CPU que tiene y cuánto tiempo pasan realmente sus tareas utilizando el tiempo de CPU. Si lo desea, puede incluso escribir su propio programador que haga algo específico como asegurarse de que todas las tareas para ese planificador siempre operen en un solo hilo.

Por lo tanto, piense en Tareas como elementos en su lista de tareas pendientes. Es posible que puedas hacer 5 cosas a la vez, pero si tu jefe te da 10000, se acumularán en tu bandeja de entrada hasta que se hagan las 5 primeras que estás haciendo. La diferencia entre las Tareas y el ThreadPool es que las Tareas (como mencioné anteriormente) le dan un mejor control sobre la relación entre los diferentes elementos de trabajo (imagínese tareas pendientes con múltiples instrucciones engrapadas), mientras que el ThreadPool solo le permite hacer cola un grupo de elementos individuales de una etapa (Funciones).

Answer 2

que está escuchando dos nociones diferentes de la tarea. El primero es la noción de un trabajo, y el segundo es la noción de un proceso.

Hace mucho tiempo (en términos informáticos), no había ningún hilo. Cada instancia en ejecución de un programa se llamaba proceso, ya que simplemente se realizaba un paso tras otro después de otro hasta que salía. Esto coincide con la idea intuitiva de un proceso como una serie de pasos, como el de una línea de ensamblaje de fábrica. El sistema operativo maneja la abstracción del proceso.

Luego, los desarrolladores comenzaron a agregar varias líneas de ensamblaje a las fábricas. Ahora un programa podría hacer más de una cosa a la vez, y ya sea una biblioteca o (más comúnmente hoy) el sistema operativo gestionaría la programación de los pasos dentro de cada hilo. Un hilo es un proceso liviano, pero un hilo pertenece a un proceso y todos los hilos en un proceso comparten memoria. Por otro lado, los procesos múltiples no pueden meterse con la memoria de los demás. Por lo tanto, los múltiples subprocesos de su servidor web pueden acceder a la misma información sobre la conexión, pero Word no puede acceder a las estructuras de datos en memoria de Excel porque Word y Excel se ejecutan como procesos separados. La idea de un proceso como una serie de pasos en realidad no coincide con el modelo de un proceso con hilos, por lo que algunas personas comenzaron a llamar "tarea de abstracción conocida anteriormente como proceso". Esta es la segunda definición de tarea que viste en la publicación del blog. Tenga en cuenta que muchas personas todavía usan el proceso de palabras para referirse a esto.

Bueno, a medida que los hilos se volvieron más comunes, los desarrolladores agregaron aún más abstracciones sobre ellos para hacerlos más fáciles de usar. Esto condujo al aumento del grupo de subprocesos, que es un "grupo" de subprocesos administrados por la biblioteca. Le pasa un trabajo a la biblioteca y la biblioteca selecciona un hilo y ejecuta el trabajo en ese hilo. El .NET Framework tiene una implementación de grupo de subprocesos y la primera vez que oyó hablar de una "tarea", la documentación realmente significaba un trabajo que pasa al grupo de subprocesos.

Por lo tanto, en cierto sentido, tanto la documentación como la publicación del blog son correctas. La sobrecarga del término tarea es la desafortunada fuente de confusión.

Answer 3

Las tareas realmente son solo un envoltorio para el código repetitivo de hilar hilos manualmente. En la raíz, no hay diferencia. Las tareas solo facilitan la gestión de los hilos, y en general son más expresivas debido a la disminución del ruido repetitivo.

Answer 4

Los subprocesos han sido parte de .Net desde la v1.0, las Tareas se introdujeron en la Task Parallel Library TPL que se lanzó en .NET 4.0.

Puede considerar una tarea como una versión más sofisticada de un subproceso. Son muy fáciles de usar y tienen muchas ventajas sobre los subprocesos de la siguiente manera:

1. Puede crear tipos de devolución en las tareas como si fueran funciones.
2. Puede utilizar el método "ContinueWith", que esperará a la tarea anterior y luego comenzará la ejecución. (Resumen de espera)
3. Resúmenes Bloqueos que deben evitarse según las directrices de mi empresa.
4. Puede usar Task.WaitAll y pasar una serie de tareas para que pueda esperar hasta que se completen todas las tareas.
5. Puede adjuntar tareas a la tarea principal, por lo tanto, puede decidir si el padre o el hijo existirán primero.
6. Puede lograr el paralelismo de datos con consultas LINQ.
7. Puede crear bucles paralelos para y foreach
8. Excepciones muy fáciles de manejar con tareas.
9. * Lo más importante es que si el mismo código se ejecuta en una máquina de un solo núcleo, solo actuará como un único proceso sin ninguna sobrecarga de hilos.

Desventaja de tareas sobre las roscas:

1. Usted necesita .Net 4.0
2. Los recién llegados que han aprendido los sistemas operativos pueden entender mejor las discusiones.
3. Nuevo en el marco por lo que no hay mucha asistencia disponible.

Algunos consejos: - Siempre use el método Task.Factory.StartNew que es semánticamente perfecto y estándar.

Tome un vistazo a tarea paralela Libray para más información http://msdn.microsoft.com/en-us/library/dd460717.aspx

Answer 5

Ampliando el comentario de Eric Lippert:

Thread s son una forma que permite su aplicación a hacer varias cosas en paralelo. Por ejemplo, su aplicación puede tener un hilo que procesa los eventos del usuario, como clics de botones y otro hilo que realiza cálculos largos. De esta manera, puedes hacer dos cosas diferentes "al mismo tiempo". Si no hiciste eso, el usuario no debería hacer clic en los botones hasta que el cálculo finalice. Entonces, Thread es algo que puede ejecutar algún código que haya escrito.

Task, por otro lado, representa una noción abstracta de algún trabajo. Ese trabajo puede tener un resultado, y puede esperar hasta que finalice el trabajo (llamando al Wait()) o decir que desea hacer algo después de que el trabajo finalice (llamando al ContinueWith()).

El trabajo más común que desea representar es realizar algunos cálculos en paralelo con el código actual. Y Task le ofrece una forma sencilla de hacerlo. Cómo y cuándo se ejecuta realmente el código está definido por TaskScheduler. El predeterminado usa un ThreadPool: un conjunto de hilos que pueden ejecutar cualquier código. Esto se hace porque la creación y el cambio de subprocesos son ineficientes.

Pero Task no tiene que estar asociado directamente con algún código. Puede usar TaskCompletionSource para crear un Task y luego establecer su resultado siempre que lo desee. Por ejemplo, puede crear un Task y marcarlo como completado cuando el usuario hace clic en un botón. Algún otro código podría esperar en ese Task y mientras está esperando, no hay código ejecutándose para ese Task.

Si desea saber cuándo usar Task y cuándo usar Thread: Task es más fácil de usar y más eficiente que la creación de sus propios Thread s. Pero a veces, necesita más control que el ofrecido por Task. En esos casos, tiene sentido usar Thread directamente.