ruby - terrajas - Modelo de actor para reemplazar el modelo de roscado?
terraja hembra (5)
Hice esta pregunta mi favorita y estoy esperando respuestas, pero como todavía no la hay, aquí está la mía.
¿Por qué y cómo un modelo de actor puede ser un modelo de concurrencia avanzada que reemplaza el enhebrado?
Los actores pueden deshacerse del estado compartido mutable, lo cual es muy difícil de codificar correctamente. (Entiendo que) los actors básicamente pueden pensar como objetos con su propio (s) hilo (s). Envía mensajes entre actores que serán puestos en cola y consumidos por el hilo dentro del actor. Entonces, cualquier estado en el actor está encapsulado, y no será compartido. Entonces, es fácil codificar bien.
ver también http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
¿Qué otros modelos son el "modelo de concurrencia avanzada"?
ver http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
Leí un capítulo de un libro (Siete idiomas en siete semanas de Bruce A. Tate) sobre Matz (Inventor de Ruby) diciendo que "eliminaría el hilo y agregaría actores, u otras características de concurrencia más avanzadas".
- ¿Por qué y cómo un modelo de actor puede ser un modelo de concurrencia avanzada que reemplaza el enhebrado?
- ¿Qué otros modelos son el "modelo de concurrencia avanzada"?
No es tanto que el modelo de actor reemplace a los hilos; a nivel de la CPU, los procesos seguirán teniendo múltiples hilos que se programan y ejecutan en los núcleos del procesador. La idea de los actores es reemplazar esta complejidad subyacente con un modelo que, según sus defensores, les facilita a los programadores la escritura de código confiable.
La idea de los actores es tener hilos de control separados (procesos en el lenguaje de Erlang) que se comunican exclusivamente mediante el envío de mensajes. Un modelo de programación más tradicional sería compartir memoria y coordinar la comunicación entre hilos utilizando mutexes. Esto aún sucede bajo la superficie en el modelo de actor, pero los detalles se abstraen y el programador recibe primitivas confiables basadas en el envío de mensajes.
Un punto importante es que los actores no necesariamente asignan 1-1 a los hilos, en el caso de Erlang, definitivamente no lo hacen, normalmente habría muchos procesos de Erlang por hilo del kernel. Entonces tiene que haber un programador que asigne actores a los hilos, y este detalle también se abstrae del programador de la aplicación.
Si está interesado en el modelo de actor, es posible que desee ver la forma en que funciona en Erlang o Scala .
Si está interesado en otros tipos de nuevo hotness concurrente, es posible que desee consultar la memoria transaccional del software , un enfoque diferente que se puede encontrar en clojure y haskell.
Cabe mencionar que muchos de los intentos más agresivos de crear modelos de concurrencia avanzada parecen estar sucediendo en los lenguajes funcionales. Posiblemente debido a la creencia (yo bebo algo de esta ayuda de kool) la inmutabilidad hace que la concurrencia sea mucho más fácil.
Ver Programación de flujo de datos . Es un enfoque, que es una capa superior al diseño OOP habitual. En algunas palabras:
- hay una escena donde residen los componentes ;
- Los componentes tienen Puertos : Productores (salida, que generan mensajes) y Consumidores (entrada, que procesa mensajes);
- hay mensajes predefinidos entre los componentes: el puerto Productor de un componente se vincula con el consumidor de otro.
La programación está pasando en 3 capas:
- escribiendo el sistema de flujo de datos (lenguaje, framework / servidor, componente API),
- Componentes de escritura (sistema, básico y orientado al dominio),
- crear el programa de flujo de datos: colocar componentes en la escena y definir mensajes entre ellos.
Los artículos de Wikipedia son un buen punto de partida para comprender el negocio: http://en.wikipedia.org/wiki/Flow-based_programming Vea también "modelo de actor", "programación de flujo de datos", etc.
Por favor, el siguiente documento