Futuros de Clojure en el contexto de los modelos de concurrencia de Scala

Question

Hola chicos: Después de estar expuestos a Actors y Clojure's Futures de Scala, siento que ambos idiomas tienen un excelente soporte para el procesamiento de datos multi core.

Sin embargo, todavía no he podido determinar las diferencias de ingeniería reales entre las funciones de simultaneidad y las ventajas y desventajas de los dos modelos. ¿Son estos idiomas complementarios u opuestos en términos de su tratamiento de las abstracciones concurrentes del proceso?

En segundo lugar, en lo que respecta a los problemas de big data, no está claro si la comunidad scala continúa admitiendo explícitamente Hadoop (mientras que la comunidad clojure sí lo hace). ¿Cómo interactúan los desarrolladores de Scala con el ecosistema de hadoop?

Cualquier apreciación de estas dos preguntas sería apreciada.

Answer 1

Los actores proporcionan una forma de manejar el posible control de intercalación y sincronización que inevitablemente se produce al intentar que varios subprocesos funcionen juntos. Cada actor tiene una cola de mensajes que procesa en orden de uno en uno a fin de evitar la necesidad de incluir bloqueos explícitos. En este caso, un futuro proporciona una forma de esperar una respuesta de un actor.

En lo que respecta a Hadoop, Twitter acaba de lanzar una biblioteca específicamente para Hadoop llamada Scalding, pero siempre que la biblioteca esté escrita para la JVM, debería funcionar con cualquier idioma.

Answer 2

Algunas soluciones están bien resueltas por agentes/actores y otras no. Esta distinción no se trata realmente de idiomas más que cómo los problemas específicos encajan dentro de las clases generales de soluciones. Esta es una comparación (muy corta) de Actores/agentes vs. Referencias para tratar de aclarar el punto de que la herramienta debe ajustarse al problema de simultaneidad.

Los actores sobresalen en la situación distribuida donde no es necesario modificar los datos al mismo tiempo. Si su problema se puede expresar simplemente transmitiendo mensajes, entonces los actores harán el truco. Los actores funcionan mal cuando necesitan modificar varias estructuras de datos relacionadas al mismo tiempo. El ejemplo canónico de esto es mover dinero entre cuentas bancarias.

Clojure's ref s son una gran solución al problema de muchos hilos que necesitan modificar lo mismo al mismo tiempo. Destacan en los sistemas multiprocesador de memoria compartida como las PC y los servidores de hoy en día. Además del ejemplo de la cuenta bancaria, Rich Hickey (el autor de clojure) usa el ejemplo de un juego de béisbol para explicar por qué esto es importante. Si quisieras usar actores para representar un juego de béisbol, antes de mover la pelota, todos los fanáticos tendrían que enviar un mensaje preguntándoles dónde estaba ... y si querían ver a un jugador atrapar la pelota, las cosas se igualarían. mas complejo.

Clojure tiene cascalog que hace que escribir trabajos de hadoop se parezca mucho a escribir clojure.