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'.Modelo de actor para reemplazar el modelo de roscado?
No es tanto que el modelo de actor reemplazará 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 le interesan otros tipos de nuevo carácter concurrente, puede consultar software transactional memory, un enfoque diferente que se puede encontrar en clojure y haskell.
Cabe mencionar que muchos de los intentos más agresivos en la creación de modelos de concurrencia avanzada parecen estar sucediendo en los lenguajes funcionales.Posiblemente debido a la creencia (yo bebo un poco de esta ayuda de kool) la inmutabilidad hace que la concurrencia sea mucho más fácil.
hice esta pregunta mi favorito y estoy a la espera de respuestas, pero ya que todavía no es, aquí es mío ..
¿Por qué y cómo un modelo de actor puede ser un modelo de concurrencia avanzada que reemplaza la rosca?
Los actores pueden deshacerse del estado compartido mutable, que es muy difícil de codificar correctamente. (Entiendo que) actors básicamente puede pensarse 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 'avanzado modelo de concurrencia'?
ver http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
Ver Dataflow Programming. Es un enfoque, que es una capa superior al diseño OOP habitual. En algunas palabras:
La programación está pasando de 3 capas:
Wikipedia son buen punto de partida para entender el negocio: http://en.wikipedia.org/wiki/Flow-based_programming Véase también "modelo de actor", "programación de flujo de datos", etc.
No estoy seguro de que llame a Dataflow una capa sobre OOP, más una alternativa a OOP con algunos crossover conceptuales. Se podría decir que OOP según Smalltalk es un lenguaje orientado a mensajes, que es de lo que se trata Dataflow. –
La implementación de un sistema de flujo de datos requiere OOP (o al menos, es la manera recomendada, natural), dependiendo de la arquitectura del DF. Escribí un sistema DF, donde el despachador y los componentes están escritos en C++, las conexiones y los parámetros se definen con un lenguaje de script propietario, que se compila con el código C++, y el resultado final es un ejecutable a.out/ELF. Entonces, la arquitectura subyacente es OOP, el sistema DF se basa en él. (Clases: Mensaje, Puerto, Consumidor, Productor, Componente (resumen) etc. y, por supuesto, muchas clases de componentes). – ern0
favor el siguiente documento
también por favor, consulte
Al principio pensé que esto era una broma, teniendo en cuenta todas las marcas registradas en el título. –
Iría más lejos y diría que la inmutabilidad aumenta la robustez del sistema. La concurrencia es una dimensión de la complejidad del software donde la diferencia de robustez es muy obvia. Los sistemas muy complejos pueden beneficiarse del uso de la inmutabilidad incluso sin necesidad de satisfacer problemas de simultaneidad. –
Además, recuerde que el modelo de actor también se puede aplicar en una red, para desarrollar un modelo asincrónico de procesamiento de solicitudes. De hecho, dado que multi-core va a ser la regla, esta abstracción podría ser incluso interesante en un nivel de os api (al menos lo es para mí). – Coyote21