¿Qué ideas falsas existen que desalientan a las personas a usar hilos? [cerrado]

12

La implementación de subprocesos en un programa es difícil, sí, sin embargo, ¿por qué algunas personas no los implementarán incluso cuando existe una necesidad obvia?

Un ejemplo: el programa tiene que cargar un conjunto de datos desde una base de datos, lo que debería hacer sería hacer la conexión y obtener los datos de la base de datos en un subproceso de trabajo y luego cargarlos en la GUI, dejando que el subproceso de la GUI responda para el usuario .

Pero no, he hablado con personas que parecen pensar que los hilos son malos y malos, y que uno debería evitarlos a toda costa. Incluso he oído que algún instructor de clase desaconsejó el uso de hilos y, por lo tanto, no quiso cubrir su uso. ¿¿¿QUÉ???

Con el hardware entrando en múltiples núcleos, creo que debemos entender mejor los hilos y no tener miedo de usarlos. Me parece un tema fascinante personalmente.

Entonces, ¿qué son las cosas que has escuchado sobre el enhebrado que son falsas?

multithreading

— Tony el león
fuente

Los inadaptados y los de bajo rendimiento no pueden manejar hilos. La verdadera pregunta es: ¿qué vas a hacer al respecto?

— Trabajo

3

Esas no son ideas falsas, pero los hilos siempre deben evitarse. Realice su arquitectura correctamente para que el soporte de subprocesos ya se haya manejado correctamente y todos los programadores no necesiten hacerlo ellos mismos. Una vez que los programadores aprendan a agregar un hilo en cada situación, tendrán grandes problemas.

— tp1

Déjame volverte la pregunta. ¿Se ha preguntado si hay enfoques alternativos para explotar las capacidades de procesamiento paralelo? O bien, ¿saltaste directamente a enhebrar porque un libro blanco lo dijo, o tal vez porque eso es lo que los mejores programadores parecían pensar que era genial? Personalmente, me gusta la idea de que los procesos livianos pasen mensajes entre sí mucho mejor que los hilos. ¿Soy flojo / estúpido / tengo prisa? Sí, y también lo estamos todos nosotros, en diversos grados.

— user1172763

19

Enhebrar es difícil

Seguro. Puede ser. Sin embargo, las personas tienen esta idea en la cabeza de que es tan difícil, que no se molestan en tratar de resolverlo.

No es que sea imposible.

— Steven Evers
fuente

2

Apoyo esta respuesta. La gente piensa que es difícil. Sin embargo, no es cuando pasas suficiente tiempo tratando de entender.

11

@Pierre, esperaría que la definición de difícil de mucha gente sea "tienes que pasar suficiente tiempo tratando de entender".

— Benjol

1

Enhebrar se está volviendo mucho más fácil con TPL y await/ asyncpalabras clave :)

— Rachel

@Pierre 303: Cuando pasas el tiempo suficiente para entender, todavía es difícil , y de hecho, las personas que lo entienden mejor son las que tienen más probabilidades de evitarlo lo más posible.

— Michael Borgwardt

9

No es la parte de subprocesos lo que es difícil, sino la necesidad de sincronización y todo lo demás que viene con el uso de subprocesos. En su ejemplo de GUI, ¿cómo le dice al hilo principal que el conjunto de datos está listo para acceder? ¿Pasa un montón de devoluciones de llamada? ¿Dispersas un montón de variables de verificación en tu código? En algunos modelos de GUI, por ejemplo, Silverlight, hay algo que se llama afinidad de subprocesos, lo que significa que no puede acceder a elementos de GUI que se encuentran en el subproceso principal desde otros subprocesos, por lo que debe apartarse de su camino para que el subproceso principal sepa que cierta información es Listo para ser procesado aún más.

Realmente no he escuchado nada falso sobre hilos. Acabo de leer un montón de estudios de casos situacionales sobre la sincronización como una perra cuando el algoritmo que está utilizando no es inherentemente paralelo.

— davidk01
fuente

Nota para uno mismo: escriba algoritmos paralelos ... gracias.

— Droogans

Colas de mensajes (igual que en MFC). Sin embargo, hacer que los programadores no saboteen la cola de mensajes (al compartir directamente los datos en la memoria), incluso cuando se trata de un delito incriminable, parece haber fallado.

— rwong

3

Enhebrar resuelve todos tus problemas

Si usted está teniendo problemas de rendimiento se debe no ir directamente a rosca.

Los hilos son livianos

Los hilos son livianos en decenas y veinte años. Engendrar miles de hilos no lo es.

Enhebrar es fácil [Java]

Es fácil crear hilos, eso no significa que se beneficiará de ellos.

— Josh K
fuente

Solo para el registro, Mac OS no le permitirá (en una instalación predeterminada) crear más de 512 hilos.

— zneak

1

Eso realmente depende de tu idioma. Generar 1 millón de hilos en Erlang apenas se nota, incluso en una computadora portátil más antigua, y mucho menos en un servidor moderno. Y en realidad, estos no son solo hilos, son procesos completos , es decir, mucho más pesados que los hilos. Además de su propio contador de programas y pila de llamadas (que son prácticamente las únicas cosas que tiene un hilo), también tienen su propio montón e incluso su propio recolector de basura.

— Jörg W Mittag

44

@ Jörg W Mittag: su comentario me confunde. ¿Cómo cambia erlang cómo el sistema operativo crea un hilo o proceso?

— Steven Evers

1

@SnOrfus: Erlang no usa hilos del sistema operativo. Hay tres implementaciones principales de Erlang en este momento: BEAM, HiPE y Erjang. BEAM y HiPE son implementaciones nativas (que incluso pueden ejecutarse sin ningún sistema operativo) e implementan sus propios procesos. Erjang se ejecuta en la JVM e implementa procesos utilizando la increíblemente brillante biblioteca Kilim.

— Jörg W Mittag

@ Jörg W Mittag: Teniendo en cuenta mi pregunta programmers.stackexchange.com/questions/28453/… , esto me parece muy interesante. Gracias.

— Steven Evers

1

Eventualmente perderá cualquier ganancia de subprocesos porque la reparación de errores locos que surgirán del uso de algunas bibliotecas / funciones que no son seguras para subprocesos (lo que no sabía) requerirá una sincronización excesiva.

Tiene una probabilidad mucho mayor de encontrar errores que no podrá corregir si usa hilos cuando no lo hace.

— Kamil Szot
fuente

Errores no reparables? No he visto uno de los de antes ..

— adamk

¿Realmente nunca has visto un error que no pudiste solucionar? ¿En el tiempo y por el pago que estaba disponible?

— Kamil Szot

Si nunca ha encontrado un error que no se puede reparar, entonces no ha estado en la industria el tiempo suficiente. En mis más de 12 años trabajando, cada proyecto que he visto tiene al menos un error que nadie ha solucionado y nadie sabe cómo solucionarlo o incluso reproducirlo. Esto incluye el código en el que he trabajado para trabajar y el código que tengo acceso para leer (código fuente abierto). Las únicas piezas de software libres de errores son las que tienen menos de 2 o 3 páginas. Pero hacer que todo su código de 1 o 2 páginas no resuelva completamente nada porque entonces tiene errores de integración.

— slebetman

1

Para resumir puntualmente por qué los subprocesos son difíciles de usar: -
Cosas verdaderas 1) Necesita la sincronización y decisiones de diseño cuidadosas sobre qué bloquear y cuándo bloquear
2) Sin control sobre el flujo del tiempo de ejecución
3) Depuración difícil
4) (Muy pocos veces) compatibilidad de plataforma: - Las bibliotecas existen para encargarse de esto

Cosas falsas: -
1) Conceptos confusos de funciones seguras y seguras para subprocesos
2) Los subprocesos se ven bien en el papel pero son muy difíciles de implementar

— Manoj R
fuente

¿Se supone que estos son verdaderos o falsos? El OP preguntó qué cosas no son ciertas y asustan a la gente para que no realice programación de subprocesos múltiples.

— Steven Evers

en realidad no necesitas bloqueos ni sincronización. También hay modelos de paso de mensajes (por ejemplo, erlang, scala) y modelos STM (por ejemplo, clojure). Y además, hay estructuras de datos seguras para subprocesos que no necesitan bloqueos (ConcurrentHashMap en java) y primitivas atómicas que no requieren bloqueos.

— Kevin

1

Si no desea escribir pruebas para su código, no use hilos.

Los subprocesos no son para el programador típico de "copiar y pegar" que no comprende los fundamentos subyacentes del sistema operativo y la arquitectura de la computadora. Dado que el 90% de los programadores solo están familiarizados con Java, estas no son realmente las personas que deberían usar hilos. Java hace que los hilos sean "fáciles", pero he visto muchos programadores que piensan que si usan estructuras sincronizadas su código funcionará en hilos ... uhm no.

Dicho esto, todo el mundo necesita comenzar en algún lugar, simplemente no haga su primer proyecto de subprocesos para actualizar el servidor de back-end de producción de su empresa.

— cmcginty
fuente

¿Me puede recomendar algunos recursos sobre cómo hacer hilos correctamente?

— Jonathan

Estoy seguro de que esto se ha abordado. Intente comenzar aquí stackoverflow.com/questions/660621/threading-best-practices

— cmcginty

El problema con esto es que incluso si tiene una cobertura de prueba del 100%, no tendrá forma de saber si sus pruebas cubrirán todos los posibles problemas con la forma en que las instrucciones se entrelazan con los recursos compartidos. Por otro lado, con una arquitectura de nada compartido, se vuelve mucho más fácil.

— Zachary K

1

Un ejemplo: el programa tiene que cargar un conjunto de datos desde una base de datos, lo que debería hacer sería hacer la conexión y obtener los datos de la base de datos en un subproceso de trabajo y luego cargarlos en la GUI, dejando que el subproceso de la GUI responda para el usuario .

No veo que esta situación represente una necesidad de usar subprocesos por al menos 4 razones:

La recuperación de datos debe ser muy rápida.
En muchas aplicaciones de la línea de negocios, el usuario no tiene nada que ver con la aplicación en el segundo o segundo que está esperando el resultado. Además, el usuario tendrá que esperar hasta que los datos vuelvan para completar la tarea deseada. La consulta, por otro lado, podría codificarse de manera inteligente de modo que solo recupere una página llena de información a la vez y otras técnicas de optimización podrían ayudar al tiempo de respuesta.
En las interfaces basadas en web, los enlaces pueden activarse con respecto al modelo de subprocesos.
El enhebrado agrega complejidad como usted admite, algunos desarrolladores en el futuro pueden no ser capaces de agregar funciones o depurar código complejo.

Mi opinión es: utilice el subproceso cuando sea necesario porque la capacidad de mantenimiento y la confiabilidad del software son más valiosas para una organización que la elegancia del código.

— Ninguna posibilidad
fuente

1

Tu primer punto me recuerda las falacias de la informática distribuida ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ). Una gran cantidad de usuarios puede comenzar a hacer clic salvajemente cuando tienen que esperar más de 1 o 2 segundos desde su punto 2 para una interfaz que no responde, lo que empeora las cosas.

— Seguro

@Secure, el enlace es interesante, gracias por compartirlo. No estoy seguro de que podamos capturar el enfoque del usuario todo el tiempo en la interfaz o incluso en todo el trabajo en estos tiempos. Estoy de acuerdo con usted en que en los sitios de comercio electrónico, no desea que el usuario se vaya del todo.

— NoChance

No estoy hablando del enfoque. Cuando el usuario hace clic en un botón y la interfaz simplemente se congela porque se consulta la base de datos, sin alguna respuesta visual de que se ha hecho algo, algunos usuarios intentan hacer clic nuevamente en el botón. Y otra vez. Luego intente hacer clic en otros botones u opciones. He visto administradores haciendo esto que deberían saberlo mejor.

— Seguro

Peor aún cuando la pantalla de resultados se dibuja por primera vez, pero se muestra vacía. No conozco la mayoría de las versiones actuales, pero el resultado de la búsqueda en Outlook anteriores es un buen mal ejemplo. Al comenzar la búsqueda, muestra "El conjunto de resultados está vacío" o algo así, durante algunos segundos con una base de búsqueda grande, mostrando los primeros resultados cuando se encuentran. Si eres demasiado impaciente o tienes prisa, ya has cambiado a la siguiente carpeta, creyendo que no hay nada allí.

— Seguro

1

@Secure, veo tu punto. Lo que está describiendo aquí muestra un buen ejemplo de una interfaz de usuario inconsistente. Lo que ha descrito también ocurre cuando busca archivos. Pero, ¿cuál es la respuesta a esto además de decirle al usuario que la búsqueda ya ha comenzado?

— NoChance