¿Es correcta mi descripción del modelo de actor?

13

Si entendí, el modelo de actor es como el modelo de objeto, pero con algunas diferencias:

  1. CADA objeto genera su propio hilo y no es un problema, incluso cuando tienes miles de objetos.
  2. Los actores no interactúan llamando a funciones y obteniendo valores de retorno, sino enviando y recibiendo mensajes.
  3. Si no violas ese modelo, tu aplicación utilizará la concurrencia en toda su potencia sin ningún riesgo de condiciones de carrera.
  4. Todo lo que puede hacer en OO puede hacer usando actores, pero mejor, el problema es que todo lo que codificamos en los últimos años se basó en OO, pero una transición es inminente.

Por ejemplo, supongamos que tengo que definir una clase / actor de vectores 3d, crear dos instancias y llamar a una operación de suma en ellos.

OBJETO ORIENTADO:

class V3d {
   constructor V3d(x,y,z) //bla
   float x,y,z;
   function sum(V3d b) 
   { 
      return V3d(x+b.x,y+b.y,z+b.z); 
   }
}

//using:
mySum = V3d(1,2,3).sum(V3d(3,2,1)) //creates 2 instances, sum, returns instantly
drawPoint(mySum) //uses the result

MODELO DE ACTOR:

actor V3d 
{
    constructor V3d(x,y,z) //bla
    float x,y,z;
    loop 
    {
       receive 'sum',b:V3d :
           send(caller,'sumResult',V3d(x+b.x,y+b.y,z+b.z))
    }
 }

//using:
send(V3d(1,2,3),'sum',V3d(3,2,1)) //creates 2 instances, send to the first one a request to sum with the second one

loop 
{
   receive 'sumResult',result:
      drawPoint(result) //receives result and draws it
}

¿Es eso? ¿O estoy completamente equivocado?

    
pregunta WindScar 28.10.2011 - 22:33

2 respuestas

12

La respuesta corta es no, no es correcta.

  1. comienza razonablemente correcto (cada Actor, al menos potencialmente se ejecuta como un subproceso independiente), pero luego en gran medida se sale de los rieles. No hay nada sobre el modelo que haga que muchos hilos funcionen bien, eso depende de la implementación. A lo sumo, la facilidad de crear muchos subprocesos ejerce presión sobre la implementación para proporcionar un subproceso eficiente. Al menos en lo que respecta al modelo, cualquier parecido entre actores y objetos es, en su mayor parte, una coincidencia. "Objeto" tiene implicaciones bastante específicas acerca de cómo combinar código y datos. Un actor generalmente involucrará tanto el código como los datos, pero implica poco sobre cómo se combinan (aparte del hecho de que los únicos datos visibles para el mundo exterior son los mensajes).

  2. La forma habitual de describir la interacción es como el envío de mensajes, sí. No tengo una cita a la mano, pero alguien demostró hace mucho tiempo que los mecanismos como las funciones virtuales de C ++ son isomorfos para el envío de mensajes (como las funciones virtuales se implementan normalmente, estás usando un desplazamiento en una tabla de video, pero si envió un desplazamiento a una tabla de mensajes, el efecto sería el mismo).

  3. No es tan simple. Si puede encontrar una copia, Henry Baker (con otra persona cuyo nombre no recuerdo en este momento) escribió un documento sobre las reglas necesarias para la consistencia de los datos en el modelo Actor.

  4. "Mejor" es altamente subjetivo en el mejor de los casos. Algunos problemas son de naturaleza altamente paralela, y realmente involucran un gran número de entidades esencialmente autónomas, con una interacción mínima que es principalmente asíncrona. Cuando ese es el caso, el modelo de actor puede funcionar muy bien. Para otros problemas, ese no es realmente el caso. Algunos problemas son casi enteramente de naturaleza serial. Otros pueden ejecutarse en paralelo, pero aún requieren una estrecha sincronización entre esas acciones (por ejemplo, esencialmente un modo similar a SIMD, donde ejecuta una instrucción a la vez, pero cada instrucción actúa en una gran cantidad de elementos de datos). Ciertamente, es posible resolver ambos tipos de problemas usando el modelo de actor, pero para tales problemas, a menudo implica una gran cantidad de trabajo adicional por poco o ningún beneficio.

respondido por el Jerry Coffin 29.10.2011 - 02:16
2

Con respecto al 1: He trabajado con una aplicación modelada por actor de un solo hilo (ish), por lo que es bastante posible ignorar el gran número de hilos que sugiere. AFAIK, los hilos no son objetos ligeros de ninguna manera, por lo que probablemente no sea conveniente tener uno para cada actor, dependiendo de cuántos actores estés usando.

Respecto a 3: ¿Estoy bastante seguro de que las condiciones de carrera pueden ocurrir en sistemas modelados por actores simplemente debido a la lógica de programación?

Respecto a 4: ¿Definir 'mejor'? Mi experiencia ha sido que la lógica asíncrona puede ser mucho más difícil de leer que las cosas síncronas. Por ejemplo, en su ejemplo anterior, no sabe qué operación es responsable de qué resultado, por lo que hay un seguimiento de mensajes adicional que hacer. Una vez que se agrega y se incluyen otros mensajes de entrada y salida en la lógica, la intención del código se distribuye en varias funciones de envío / recepción.

Habiendo dicho todo eso, soy un gran fanático del uso de modelos de actores para las capas superiores de una aplicación. Puede facilitar el desacoplamiento, ya que agregar dependencias es un poco más difícil que agregar una función. Tampoco tengo mucha experiencia con un nivel más alto que los lenguajes Java, y otros paradigmas pueden soportar la asincronía de una manera más fundamental.

    
respondido por el tugs 28.10.2011 - 23:53

Lea otras preguntas en las etiquetas