Cuándo usar Multithread?

Question

¿Cuándo utiliza los hilos en una aplicación? Por ejemplo, en operaciones simples de CRUD, uso de smtp, llamando a servicios web que pueden tardar un tiempo si el servidor enfrenta problemas de banda, etc.

Para ser honesto, no sé cómo determinar si necesito use un hilo (sé que debe ser cuando estamos exceptuando que una operación tardará un poco en completarse).

Esto puede ser una pregunta "novato", pero será genial si compartes conmigo tu experiencia en hilos.

Gracias

Answer 1

Agregué C# y.NET etiquetas a su pregunta porque menciona C# en su título. Si eso no es exacto, siéntase libre de eliminar las etiquetas.

Existen diferentes estilos de subprocesamiento múltiple. Por ejemplo, hay operaciones asíncronas con funciones de devolución de llamada. .NET 4 introduce la biblioteca paralela de Linq. El estilo de multihilo que usarías, o si usarías alguno, depende de lo que intentas lograr.

La ejecución paralela, como por ejemplo lo que Linq generalmente intenta hacer, aprovecha múltiples núcleos de procesador ejecutando instrucciones que no necesitan esperar datos entre sí. Hay muchas fuentes para dichos algoritmos fuera de Linq, como this. Sin embargo, es posible que la ejecución en paralelo no le sea posible o que no sea adecuada para su aplicación.

El subprocesamiento múltiple más tradicional aprovecha el subprocesamiento dentro de la biblioteca .NET (en este caso) proporcionada por System.Thread. Recuerde que hay algunos gastos generales en los procesos de inicio en los subprocesos, de modo que solo utilice los subprocesos cuando las ventajas de hacerlo superen esta sobrecarga. En general, solo desearía utilizar este tipo de subprocesamiento múltiple de un solo procesador cuando la tarea que se ejecuta bajo el hilo tenga largos espacios en los que el procesador podría estar haciendo otra cosa. Por ejemplo, las E/S del disco duro (y, en consecuencia, de un sistema de base de datos que usa una) son muchos órdenes de magnitud más lentos que el acceso a la memoria. El acceso a la red también puede ser lento, como otro ejemplo. El subprocesamiento múltiple podría permitir que se ejecute otro proceso mientras se espera que estas operaciones lentas (en comparación con el procesador) se completen.

Otro ejemplo cuando he usado el multithreading tradicional es almacenar en caché algunos valores la primera vez que se accede a una página ASP.NET en particular dentro de una sesión. Inicié un hilo para que el usuario no tenga que esperar a que se complete el almacenamiento en caché antes de interactuar con la página. También regulé el comportamiento cuando el almacenamiento en caché no se completa antes de que el usuario solicite otra página, de modo que, si el almacenamiento en caché no se completa, no es un problema. Simplemente hace más solicitudes más rápido que antes eran demasiado lentas.

Considere también el costo que tiene el multihilo para la mantenibilidad de su aplicación. Las aplicaciones con subprocesos pueden ser más difíciles de depurar, por ejemplo.

Espero que esto responda a su pregunta al menos de alguna manera.

Answer 2

Una razón para utilizar hilos es dividir las tareas grandes, vinculados a la CPU a través de un número de CPU/núcleos, para terminar más rápido. Otra es permitir que una tarea extendida se ejecute de forma asincrónica, de modo que el primer plano pueda seguir siendo receptivo mientras se ejecuta.

Sus ejemplos parecen concentrarse en el segundo de estos. Si bien puede ser una buena razón, si puede usar E/S asincrónicas en su lugar, generalmente es preferible (por ejemplo, casi cualquier cosa que use sockets puede/estará mejor si usa el socket (s) de forma asincrónica). La E/S asincrónica es más fácil de cancelar y, por lo general, también tendrá una sobrecarga de CPU más baja.

Answer 3

Puede usar subprocesos cuando necesite diferentes rutas de ejecución. Esto lleva (cuando se hace correctamente) a aplicaciones más receptivas y/o más rápidas, pero también conduce a un código y depuración más complejos.

En un escenario CRUD simple quizás no sea tan útil, pero tal vez su UI consuma un servicio web lento. Si su código está vinculado a su subproceso de interfaz de usuario, tendrá una interfaz de usuario que no responde entre las llamadas de servicio.

En ese caso, usando System.Threading.Threads tal vez sean exagerados porque no necesita tanto control. Usar un BackgrounWorker tal vez sea una mejor opción.

Enhebrar es algo difícil de dominar, pero los beneficios cuando se usan correctamente son enormes, el rendimiento es el más común.

Answer 4

De alguna manera, usted ha respondido su pregunta usted mismo. Usar hilos cada vez que ejecuta operaciones que consumen mucho tiempo es la elección correcta. También debes hacerlo en situaciones en las que quieras hacer las cosas más rápido. Por ejemplo, desea procesar cierta cantidad de archivos; cada archivo puede procesarse por diferentes hilos.

Al usar hilos, puede utilizar mejor la potencia de las máquinas procesadoras/multi-núcleo.

Monitorización de algunos datos en el fondo de su aplicación.

Hay docenas de tales escenarios.

Answer 5

José Albahari lo resumió muy bien here:

• El mantenimiento de una interfaz de usuario sensible
• Haciendo uso eficiente de una CPU bloqueado de otro modo
• Programación paralela
• Ejecución especulativa
• Permitir peticiones a ser procesado simultáneamente

Answer 6

Al darse cuenta mi comentario puede ser suficiente como una respuesta ...

me gusta ver escenarios multi-threading desde una perspectiva de los recursos. En otras palabras, interfaz de usuario (gráficos), redes, disco IO, CPU (núcleos), RAM, etc. Me parece que ayuda a la hora de decidir dónde usar multi-hilos en el sentido general al menos.

El razonamiento detrás de esto es simplemente que puedo aprovechar un recurso en un hilo específico (por ejemplo, disco IO) mientras que al mismo tiempo uso otro hilo para lograr algo más usando un recurso diferente.