¿Hay alguna explicación buena y breve de cómo funciona actores en comparación con los hilos?¿Cómo funcionan los actores en comparación con los hilos?
¿No se puede ver un hilo como actor y enviar mensajes a otros hilos? Veo alguna diferencia, pero no está tan claro para mí. ¿Puedo usar Actors en cualquier idioma usando hilos de manera diferente?
El modelo de actor opera al pasar mensajes. Los procesos individuales (actores) pueden enviar mensajes de forma asincrónica entre sí. Lo que lo distingue de lo que normalmente pensamos es el modelo de subprocesamiento, es que no existe (en teoría al menos) estado compartido. Y si uno cree (justificadamente, creo) que el estado compartido es la raíz de todo mal, entonces el modelo de actor se vuelve muy atractivo.
No deberíamos emocionarnos, sin embargo. El modelo de actor no hace (a diferencia de algunas acusaciones) que sea imposible tener puntos muertos. El modelo de actor tampoco evita que tengas conflictos por recursos entre diferentes procesos, por ejemplo, colas de mensajes. El modelo solo está "libre de bloqueos" por encima de cierto nivel. En un nivel inferior, para coordinar las colas de mensajes, aún se requiere bloqueo.
¿No se puede ver un hilo como actor y enviar mensajes a otros hilos?
Bueno, sí y no. No, si solo está utilizando el método de colocar mutexes en ubicaciones de memoria compartida. Luego, los hilos comparten este estado: ambos tienen acceso a esta memoria, pueden leerla, reescribirla, etc. Pero puedes construir un modelo de actor sobre un modelo de subprocesamiento, y de hecho todas las implementaciones de actores tienen subprocesos debajo. He pirateado algo así (muy mal) dando a cada hilo una cola protegida por un mutex, solo por diversión. Para tener una idea de cómo se gestiona la impedancia del hilo del actor, consulte my question from a year ago.
¿Puedo utilizar el Actor Modelo en cualquier idioma usando hilos de manera diferente?
Sí, pero tomará un poco más de trabajo. Su idioma favorito puede tener una biblioteca de paso de mensajes, por lo que sería lo primero que debe investigar. Además, debe investigar el uso de estructuras de datos inmutables. Tenga en cuenta que si una estructura de datos es inmutable, entonces esencialmente ha tratado el problema del "estado compartido": varios hilos pueden contener referencias a datos inmutables sin que suceda nada malo. Hay una razón por la cual los lenguajes de actores también suelen ser lenguajes funcionales (erlang, scala).
Es posible que también desee echar un vistazo a Software Transactional Memory, que es un modelo diferente pero también convincente. Clojure es mi ejemplo favorito de eso.
No diría que los actores siempre pasan mensajes de forma asíncrona, eso sería demasiado lento. Por ejemplo, el proyecto JActor utiliza mensajes bidireccionales (solicitud/respuesta) para modelar mejor una llamada a un método. Y la mayoría de las solicitudes se atienden de forma sincrónica.
JActor (una biblioteca de Java) tampoco usa bloqueos. Solo algunas estructuras de datos atómicas y concurrentes, con algunos semáforos incluidos. La transmisión de mensajes es de unos 8 mil millones de mensajes por segundo.
El modelo de actor se define solo mediante el uso de comunicación asincrónica (http://en.wikipedia.org/wiki/Actor_model). Si JActor no está haciendo eso, entonces no es 100% solo el modelo de actor. Simplemente puede usar el modelo de actor como una de muchas de sus características. –
Cuanto más uso de mensajes asíncronos que pasa modelos de concurrencia base (por ejemplo, actores o asíncrono/espero), cuanto más pienso que son sólo dual del modelo antiguo, estándar sincronizada bloqueo concurrencia. El envío de mensajes asíncronos no es realmente más fácil o más difícil que el uso de bloqueos y monitores.De hecho, no hay un estado mutable compartido, sino solo al * nivel de actor único *. Pero un actor todavía tiene un estado mutable, y en realidad es observable por todos los actores que cooperan con él. Por lo tanto, puede tener todos los mismos problemas: interbloqueos, bloqueos, inanición, condiciones de carrera, etc. –