Implementación del modelo de actor

En informática , la implementación del modelo de actor se refiere a cuestiones de implementación para el modelo de actor .

Cubo Cósmico

El Cubo Cósmico de Caltech fue desarrollado por Chuck Seitz y otros en Caltech, proporcionando soporte arquitectónico para sistemas de actores. Una diferencia significativa entre el Cubo Cósmico y la mayoría de los demás procesadores paralelos es que esta máquina de instrucciones múltiples y datos múltiples (MIMD) utiliza el paso de mensajes , en lugar de variables compartidas, para la comunicación entre procesos concurrentes. Este modelo computacional se refleja en la estructura del hardware y el sistema operativo , y también es la comunicación explícita de paso de mensajes que ve el programador. Según Seitz [1985]:

Una de las premisas del experimento del Cubo Cósmico era que la comunicación entre nodos debía escalar bien a un número muy elevado de nodos. Una red directa como el hipercubo satisface este requisito, tanto en lo que respecta al ancho de banda total alcanzado a través de los numerosos canales de comunicación concurrentes como a la viabilidad de su implementación. El hipercubo es, de hecho, una variante distribuida de una red de conmutación logarítmica indirecta como las redes Omega o Banyan : en las organizaciones de almacenamiento compartido, se suelen utilizar rutas de comunicación uniformes. Sin embargo, con la arquitectura del hipercubo, las rutas de comunicación pueden atravesar un número variable de canales, lo que da lugar a diferentes latencias. Esto permite optimizar el rendimiento mediante la ubicación de los procesos en los nodos en función de la localidad de comunicación.

Máquina J

La J-Machine fue desarrollada por Bill Dally y otros en el MIT, proporcionando soporte arquitectónico adecuado para actores. Esto incluía lo siguiente:

mensajería asíncrona
Un espacio uniforme de direcciones de actores al que se podrían enviar mensajes simultáneamente, independientemente de si el actor receptor era local o no local.
Una forma de segmentación de actores (véase el modelo de actor ).

Se desarrolló Smalltalk concurrente (que se puede modelar utilizando actores ) para programar la máquina J.

Lenguaje de programación de actores prototipo

Hewitt [2006] presentó un prototipo de lenguaje de programación de actores en el sentido de que expresa directamente aspectos importantes del comportamiento de los actores. Los mensajes se expresan en XML utilizando la notación :<tag>[<element>₁ ... <element>] for

“<”<tag>“>” <element>₁ ... <element>_n “<”/<tag>“>”

La semántica del lenguaje de programación se define representando cada construcción del programa como un actor con su propio comportamiento. La ejecución se modela mediante el intercambio de mensajes Eval entre estas construcciones durante el tiempo de ejecución.

Actores ambientales

Cada Evalmensaje tiene la dirección de un actor que actúa como un entorno con los enlaces de los identificadores del programa. Los actores de entorno son inmutables, es decir, no cambian. Cuando Request[Bind[identifier value] customer]un actor de entorno recibe un mensaje, se crea un nuevo actor de entorno tal que cuando el nuevo actor de entorno recibe un mensaje, Request[Lookup[identifier’] customer’]si identifieres el mismo que identifier’envía un mensaje customer’Returned[value], de lo contrario envía otro mensaje Environment Request[Lookup[identifier’] customer’]. Lo anterior se basa en un actor EmptyEnvironmentque, cuando recibe un mensaje Request[Lookup[identifier] customer], envía otro mensaje . Cuando recibe una solicitud, actúa como se indicó anteriormente.customerThrown[NotFound[identifier]]BindEmptyEnvironmentEnvironment

Expresiones

El lenguaje de programación prototipo tiene expresiones de los siguientes tipos:

<identificador>: Cuando Request[Eval[environment] customer]se reciba, envíeenvironmentRequest[Lookup[<identifier>] customer]

enviar <destinatario> < comunicación >: Cuando Request[Eval[environment] customer]se recibe, enviar donde hay un nuevo actor tal que<recipient>Request[Eval[environment] evalCustomer₁]evalCustomer₁; cuando reciba la comunicación , entonces envíeevalCustomer₁Returned[theRecipient]<communication>; Request[Eval[environment] evalCustomer₂]¿Dónde hay un nuevo actor tal que...?evalCustomer₂; cuando reciba la comunicación , entonces envíe .evalCustomer₂Returned[theCommunication]theRecipienttheCommunication

<destinatario> . <mensaje>: Cuando Request[Eval[environment] customer]se reciba, envíe de tal manera que<recipient>Request[Eval[environment] evalCustomer₁]; cuando recibe la comunicación , entonces envía de tal manera queevalCustomer₁Returned[theRecipient]<message>Request[Eval[environment] evalCustomer₂]; cuando reciba la comunicación , entonces envíeevalCustomer₂Returned[theMessage]theRecipient; Request[theMessage customer]

receptor ... < patrón > _i< expresión > _i ...: Cuando Request[Eval[environment] customer]se reciba, envíe customerun nuevo actor theReceiverde tal manera que; cuando theReceiverrecibe una comunicación com, entonces crea un nuevo bindingCustomerentorno y envíalo.; Request[Bind[<pattern>_i com] bindingCustomer]y; si bindingCustomerrecibe Returned[environment’], enviar<expression>_i; Request[Eval[environment’]]; de lo contrario si bindingCustomerrecibe Thrown[...], intente<pattern>_i+1

comportamiento ... < patrón > _i< expresión > _i ...

Cuando Request[Eval[environment] customer]se reciba, envíe al cliente un nuevo actor theReceivertal que

cuando theReceiverreciba Request[message customer’], entonces cree uno nuevo bindingCustomery envíeloenvironment

Request[bind[<pattern>_i message] customer’]y

si bindingCustomerrecibe Returned[environment’], enviar<expression>_i
Request[Eval[environment’] customer’]
de lo contrario si bindingCustomerrecibe Thrown[...], intente<pattern>_i+1

{ < expresión > ₁ , < expresión > ₂ }: Cuando Request[Eval[environment] customer]se recibe, envía y envía simultáneamente .<expression>₁Request[Eval[environment]]<expression>₂Request[Eval[environment]] customer]

sea <identificador> = < expresión > _valoren < expresión > _cuerpo: Cuando message[Eval[environment] customer]se reciba, entonces cree uno nuevo evalCustomery envíelo.<expression>_value; Request[Eval[environment] evalCustomer₁.; Cuando evalCustomerreciba Returned[theValue], cree uno nuevo bindingCustomery envíelo.environment; Request[bind[<identifier> theValue] bindingCustomer]; Cuando bindingCustomerreciba Returned[environment’], envíe<expression>_bodyRequest[Eval[environment’] customer]

serializador < expresión >: Cuando Request[Eval[environment] customer]se recibe, entonces envía customerReturned[theSerializer]donde theSerializeres un nuevo actor de tal manera que las comunicaciones enviadas a theSerializerse procesan en orden FIFO con un actor de comportamiento que es inicialmente y<expression>.Eval[environment]; Cuando comse recibe la comunicación por theSerializer, entonces envía el actor de comportamiento Request[com customer’]donde customer’es un nuevo actor tal que; cuando customer’recibe Returned[theNextBehavior], se theNextBehaviorutiliza como actor de comportamiento para la siguiente comunicación recibida por theSerializer.

Programa de ejemplo

A continuación se muestra un ejemplo de programa para una celda de almacenamiento simple que puede contener cualquier dirección de actor:

Célula ≡

receptor

Solicitud[Crear[inicial] cliente]

enviar cliente Devuelto[ serializador ReadWrite(inicial)]

El programa anterior, que crea una celda de almacenamiento, utiliza el comportamiento ReadWrite, que se define de la siguiente manera:

LeerEscribir(contenido) ≡

comportamiento

Solicitud[leer[] cliente]

{ enviar cliente Returned[contents], ReadWrite(contents)}

Solicitud[escribir[x] cliente]

{ enviar cliente Returned[], ReadWrite(x)}

El comportamiento descrito anteriormente se ejecuta en paralelo, es decir, puede que esté procesando un mensaje de lectura o escritura anterior mientras procesa otro. Por ejemplo, la siguiente expresión crea una celda x con el valor inicial 5 y, a continuación, escribe simultáneamente en ella los valores 7 y 9.

sea x = Cell.Create[5] en {x.write[7], x.write[9], x.read[]}

El valor de la expresión anterior es 5, 7 o 9.

Véase también

Referencias

Henry Baker y Carl Hewitt. La recolección incremental de basura de procesos. Actas del Simposio sobre Lenguajes de Programación de Inteligencia Artificial. SIGPLAN Notices 12, agosto de 1977.
Peter Bishop, Sistemas informáticos modularmente extensibles con un espacio de direcciones muy grande. Tesis doctoral del MIT EECS. Junio de 1977.
Henry Baker. Sistemas de actores para computación en tiempo real. Tesis doctoral del MIT EECS. Enero de 1978.
Carl Hewitt y Russ Atkinson. Técnicas de especificación y prueba para serializadores. Revista IEEE de Ingeniería de Software. Enero de 1979.
Ken Kahn. Tesis doctoral en Ingeniería Eléctrica e Informática del MIT , titulada "Una teoría computacional de la animación" . Agosto de 1979.
Carl Hewitt, Beppe Attardi y Henry Lieberman. Delegación en el protocolo de paso de mensajes. Actas de la Primera Conferencia Internacional sobre Sistemas Distribuidos. Huntsville, Alabama. Octubre de 1979.
Bill Kornfeld y Carl Hewitt. La metáfora de la comunidad científica. IEEE Transactions on Systems, Man, and Cybernetics. Enero de 1981.
Henry Lieberman. Pensar en muchas cosas a la vez sin confundirse: Paralelismo en el Acto 1. Memorando 626 del MIT sobre IA. Mayo de 1981.
Henry Lieberman. Un adelanto del Acto 1. Memorando 625 del MIT sobre IA. Junio de 1981.
Bill Kornfeld. Paralelismo en la resolución de problemas. Tesis doctoral en Ingeniería Eléctrica e Informática del MIT. Agosto de 1981.
Daniel Theriault. Introducción al lenguaje Act-1. Memorando 672 del MIT sobre IA. Abril de 1982.
Henry Lieberman y Carl Hewitt. Un recolector de basura en tiempo real basado en la vida útil de los objetos. CACM, junio de 1983.
Daniel Theriault. Problemas en el diseño e implementación del Acto 2. Informe técnico 728 del MIT sobre IA. Junio de 1983.
Henry Lieberman. Un simulador orientado a objetos para la Conferencia sobre Apicultura de la Asociación Estadounidense de Inteligencia Artificial, Washington, DC, agosto de 1983.
Carl Hewitt y Henry Lieberman. Problemas de diseño en la arquitectura paralela para inteligencia artificial. Memorando 750 del MIT sobre IA. Noviembre de 1983.
Charles Seitz. El Cubo Cósmico CACM. Enero de 1985.
Carl Manning. Traveler: el observatorio de actores ECOOP 1987. También aparece en Lecture Notes in Computer Science, vol. 276.
Carl Manning, Acore: El diseño de un lenguaje de actores central y su compilación . Tesis de maestría. MIT EECS. Mayo de 1987.
William Athas y Charles Seitz, Multicomputadoras: computadoras concurrentes con paso de mensajes, IEEE Computer, agosto de 1988.
William Athas y Nanette Boden Cantor: Un sistema de programación de actores para computación científica en las Actas del Taller de la NSF sobre Programación Concurrente Basada en Objetos. 1988. Número especial de SIGPLAN Notices.
Jean-Pierre Briot. De objetos a actores: Estudio de una simbiosis limitada en Smalltalk-80. Rapport de Recherche 88-58, RXF-LITP, París, Francia, septiembre de 1988.
William Dally y Wills, D. Mecanismos universales para la concurrencia PARLE '89.
W. Horwat, A. Chien y W. Dally. Experiencia con CST: Programación e implementación PLDI. 1989.
Akinori Yonezawa , Ed. ABCL: Un sistema concurrente orientado a objetos. MIT Press. 1990.
Carl Hewitt y Gul Agha. Lenguajes de cláusulas de Horn protegidas: ¿son deductivos y lógicos? en Inteligencia Artificial en el MIT, vol. 2. MIT Press 1991.
Carl Hewitt y Jeff Inman. DAI Betwixt and Between: From "Intelligent Agents" to Open Systems Science. IEEE Transactions on Systems, Man, and Cybernetics. Noviembre/Diciembre de 1991.
William Dally, et al. El procesador controlado por mensajes: un nodo de procesamiento multicomputadora con mecanismos eficientes. IEEE Micro. Abril de 1992.
Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer. Nota del W3C sobre el Protocolo Simple de Acceso a Objetos (SOAP) 1.1 . Mayo de 2000.
Edward A. Lee y Stephen Neuendorffer (junio de 2004). "Clases y subclases en el diseño orientado a actores" (tesis doctoral - resumen extendido). Conferencia sobre métodos y modelos formales para el codiseño (MEMOCODE).
Carl Hewitt. El declive recurrente de la programación lógica y su posible resurgimiento. ¿Qué falló y por qué?: Lecciones de la investigación y las aplicaciones de la IA. Informe técnico SS-06-08. AAAI Press. Marzo de 2006.