¿Cuándo se debe usar el modelo Actor?

Question

¿Cuándo se debe usar el Actor Model?

Ciertamente no garantiza un entorno sin intersticios.

Actor A puede esperar a que un mensaje de B mientras que B espera a A.

Además, si un actor tiene que asegurarse de que su mensaje se procesa antes de pasar a la siguiente tarea, se tendrá que enviar una mensaje y espere a que aparezca el mensaje "su mensaje fue procesado" en lugar del bloqueo directo.

¿Cuál es el poder del modelo?

Answer 1

Teniendo en cuenta algún problema de simultaneidad, ¿qué buscarías para decidir si usar actores o no?

Primero quisiera definir el problema ... ¿es la motivación principal una aceleración de un bucle anidado o una recursión? Si es así, un enfoque simple basado en tareas o un enfoque de bucle paralelo funcionará bien para usted (en lugar de los actores).

Sin embargo, si tiene un sistema más complejo que involucra dependencias y coordina el estado compartido, entonces un enfoque de actor puede ayudar. Específicamente mediante el uso de actores y la semántica de transmisión de mensajes, a menudo puede evitar el uso de bloqueos explícitos para proteger el estado compartido haciendo copias de ese estado (mensajes) y reaccionando ante ellos.

Puede hacerlo fácilmente con los clásicos problemas de sincronización, como los filósofos del comedor y el problema de los peluqueros dormidos. Pero también puede usar el "actor" para ayudar con patrones más modernos, es decir, su fachada podría ser un actor, su vista modelo y su controlador también podrían ser actores que se comunican entre sí.

Otra cosa que he observado es que la semántica de los actores se puede aprender por la mayoría de los desarrolladores y es más "segura" que sus contrapartes bloqueadas. Esto se debe a que aumentan el nivel de abstracción y le permiten centrarse en coordinar el acceso a esos datos en lugar de proteger todos los accesos a los datos con bloqueos. Como ejemplo, imagine que tiene una clase simple con un miembro de datos. Si elige colocar un candado en esa clase para proteger el acceso a ese miembro de datos, entonces cualquier método en esa clase deberá asegurarse de que están accediendo a ese miembro de datos bajo el candado. Esto se vuelve particularmente problemático cuando otros (o usted) modifican la clase en una fecha posterior, tienen que recordar para usar ese bloqueo.

Por otro lado, si esa clase se convierte en un actor y el miembro de datos se convierte en una memoria intermedia o puerto se comunica con a través de mensajes, usted no tiene que acordarse de tomar la cerradura, porque la semántica se construyen en el búfer y se sabrá muy explícitamente si va a bloquear eso según el tipo de buffer.

-Rick

Answer 2

El uso de actor es "natural" en al menos dos casos:

1. Cuando se puede descomponer el problema en un conjunto de tareas independientes.
2. Cuando puede descomponer su problema en un conjunto de tareas vinculadas por un worflow claro (es decir, dataflow programming).

Por ejemplo, si procesa datos complejos utilizando una serie de filtros, es fácil utilizar una cartera de actores donde cada actor recibe datos de un actor ascendente y establece datos para un actor intermedio.

Por supuesto, este flujo de datos no debe ser lineal y si un paso es lento en su canalización, puede utilizar un conjunto de actores haciendo el mismo trabajo. Otra forma de resolver los problemas de equilibrio de carga sería utilizar un enfoque basado en la demanda y organizado con un tipo de sistema virtual Kanban.

Por supuesto, necesitará la sincronización entre los actores en casi todos los casos interesantes, pero a diferencia del enfoque clásico de múltiples hilos, esta sincronización es realmente "concreta". Puedes imaginarte muchachos en una fábrica, imagina posibles problemas (los trabajadores se quedan sin trabajo, las operaciones previas son demasiado rápidas y los productos intermedios necesitan un gran lugar de almacenamiento, etc.) Por analogía, puedes encontrar una solución más fácilmente.