Hilos frente a Async

He estado leyendo sobre el modelo de programación con subprocesos versus el modelo asincrónico de este artículo realmente bueno. http://krondo.com/blog/?p=1209

Sin embargo, el artículo menciona los siguientes puntos.

1. Un programa asincrónico simplemente superará a un programa de sincronización cambiando entre tareas siempre que haya una E / S.
2. Los subprocesos son administrados por el sistema operativo.

Recuerdo haber leído que los subprocesos son administrados por el sistema operativo moviéndose alrededor de los TCB entre Ready-Queue y Waiting-Queue (entre otras colas). En este caso, los hilos tampoco pierden tiempo esperando, ¿verdad?

A la luz de lo mencionado anteriormente, ¿cuáles son las ventajas de los programas asíncronos sobre los programas con subprocesos?

1. Es muy difícil escribir código que sea seguro para subprocesos. Con el código asíncrono, sabe exactamente dónde cambiará el código de una tarea a la siguiente y, por lo tanto, las condiciones de carrera son mucho más difíciles de conseguir.
2. Los subprocesos consumen una buena cantidad de datos, ya que cada subproceso debe tener su propia pila. Con el código asíncrono, todo el código comparte la misma pila y la pila se mantiene pequeña debido a que se desenrolla continuamente entre tareas.
3. Los subprocesos son estructuras del sistema operativo y, por lo tanto, son más memoria para que la plataforma admita. No existe tal problema con las tareas asincrónicas.

Hay dos formas de crear hilos:

subprocesos sincrónicos : el padre crea uno (o más) subprocesos secundarios y luego debe esperar a que cada hijo termine. El subproceso síncrono a menudo se denomina modelo de unión de bifurcación .

subprocesos asincrónicos : el padre y el hijo se ejecutan de forma simultánea / independiente uno del otro. Los servidores multiproceso suelen seguir este modelo.

recurso - http://www.amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/0470128720

1. Suponga que tiene 2 tareas, lo que no implica ninguna E / S (en una máquina multiprocesador). En este caso, los subprocesos superan a Async. Porque Async, como un programa de un solo hilo, ejecuta sus tareas en orden. Pero los subprocesos pueden ejecutar ambas tareas simultáneamente.

2. Suponga que tiene 2 tareas, que involucran IO (en una máquina multiprocesador). En este caso, tanto Async como Threads funcionan más o menos igual (el rendimiento puede variar según la cantidad de núcleos, la programación, la intensidad del proceso de la tarea, etc.). Además, Async requiere menos cantidad de recursos, menos gastos generales y menos complejo de programar sobre un programa de subprocesos múltiples.

¿Cómo funciona? El subproceso 1 ejecuta la Tarea 1, ya que está esperando IO, se mueve a la cola de espera IO. De manera similar, el subproceso 2 ejecuta la Tarea 2, dado que también involucra IO, se mueve a la cola de espera de IO. Tan pronto como se resuelve su solicitud de E / S, se mueve a la cola lista para que el programador pueda programar el hilo para su ejecución.

Async ejecuta la Tarea 1 y sin esperar a que se complete su IO, continúa con la Tarea 2 y luego espera a que IO de ambas tareas se complete. Completa las tareas en el orden de finalización IO.

Async más adecuado para tareas que involucran llamadas de servicio web, llamadas de consulta de base de datos, etc., subprocesos para tareas intensivas en procesos.

El siguiente video explica sobre Async vs Threaded modely también cuándo usar, etc., https://www.youtube.com/watch?v=kdzL3r-yJZY

Espero que esto sea útil.

En primer lugar, tenga en cuenta que muchos de los detalles de cómo se implementan y programan los subprocesos son muy específicos del sistema operativo. En general, no debería tener que preocuparse por los subprocesos que se esperan entre sí, ya que el sistema operativo y el hardware intentarán organizarlos para que se ejecuten de manera eficiente, ya sea de forma asíncrona en un sistema de un solo procesador o en paralelo en multiprocesadores.

Una vez que un hilo ha terminado de esperar algo, digamos E / S, se puede considerar que se puede ejecutar. Los subprocesos que se pueden ejecutar se programarán para su ejecución en algún momento pronto. Si esto se implementa como una cola simple o algo más sofisticado, nuevamente, es específico del sistema operativo y del hardware. Puede pensar en el conjunto de subprocesos bloqueados como un conjunto en lugar de una cola estrictamente ordenada.

Tenga en cuenta que en un sistema de un solo procesador, los programas asincrónicos como se definen aquí son equivalentes a los programas enhebrados.

E / S asíncrona significa que ya hay un hilo en el controlador que hace el trabajo, por lo que está duplicando la funcionalidad e incurriendo en algunos gastos generales. Por otro lado, a menudo no se documenta cómo se comporta exactamente el hilo del controlador, y en escenarios complejos, cuando desea controlar el comportamiento del tiempo de espera / cancelación / inicio / parada, la sincronización con otros hilos, tiene sentido implementar su propio hilo. A veces también es más fácil razonar en términos sincronizados.

ver http://en.wikipedia.org/wiki/Thread_(computing)#I.2FO_and_scheduling

Sin embargo, el uso de llamadas al sistema de bloqueo en subprocesos de usuario (a diferencia de subprocesos del kernel) o fibras puede ser problemático. Si un hilo de usuario o una fibra realiza una llamada al sistema que se bloquea, los otros hilos y fibras del usuario en el proceso no pueden ejecutarse hasta que vuelva la llamada al sistema. Un ejemplo típico de este problema es al realizar E / S: la mayoría de los programas están escritos para realizar E / S sincrónicamente. Cuando se inicia una operación de E / S, se realiza una llamada al sistema y no regresa hasta que se completa la operación de E / S. En el período intermedio, todo el proceso es "bloqueado" por el núcleo y no puede ejecutarse, lo que priva a otros hilos y fibras del usuario en el mismo proceso para que no se ejecuten.

De acuerdo con esto, todo su proceso podría bloquearse y no se programará ningún hilo cuando un hilo esté bloqueado en IO. Creo que esto es específico del sistema operativo y no siempre se mantendrá.