En informática , la implementación del modelo Actor se refiere a problemas de implementación del modelo Actor .
Cubo cósmico
El Cubo Cósmico de Caltech fue desarrollado por Chuck Seitz et al. en Caltech brindando soporte arquitectónico para sistemas Actor. Una diferencia significativa entre el Cosmic Cube y la mayoría de los otros procesadores paralelos es que esta máquina de datos múltiples de instrucciones múltiples 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 premisa del experimento del Cubo Cósmico era que la comunicación entre los entrenudos debería escalar bien a un gran número de nodos. Una red directa como el hipercubo satisface este requisito, tanto con respecto al ancho de banda agregado logrado a través de los muchos canales de comunicación concurrentes como a la viabilidad de la implementación. El hipercubo es en realidad una variante distribuida de una red de conmutación logarítmica indirecta como las redes Omega o Banyan : del tipo que podría usarse en organizaciones de almacenamiento compartido. Sin embargo, con el hipercubo, las rutas de comunicación atraviesan diferentes números de canales y, por lo tanto, exhiben diferentes latencias. Es posible, por tanto, aprovechar la localidad de comunicación al colocar procesos en nodos.
J – Machine
La máquina J fue desarrollada por Bill Dally et al. en el MIT brindando soporte arquitectónico adecuado para Actores. Esto incluyó lo siguiente:
- Mensajería asincrónica
- Un espacio uniforme de direcciones de actores al que se pueden enviar mensajes simultáneamente, independientemente de si el actor receptor era local o no local.
- Una forma de canalización de Actor (ver modelo de Actor )
Smalltalk concurrente (que se puede modelar usando Actors ) fue desarrollado para programar la J Machine.
Lenguaje de programación de actor prototipo
Hewitt [2006] presentó un prototipo de lenguaje de programación Actor en el sentido de que expresa directamente aspectos importantes del comportamiento de los actores. Los mensajes se expresan en XML utilizando la notación:
- “<”
“>” 1 ... n “<”/ “>”
La semántica del lenguaje de programación se define definiendo cada construcción del programa como un actor con su propio comportamiento. La ejecución se modela haciendo que los mensajes Eval pasen entre las construcciones del programa durante la 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 de programa. Los actores ambientales son inmutables, es decir, no cambian. Cuando Request[Bind[identifier value] customer]es recibido por un entorno de actor, se crea un nuevo actor de entorno de modo que cuando el nuevo actor de entorno recibe Request[Lookup[identifier’] customer’], si identifieres lo mismo que identifier’enviar customer’ Returned[value], de lo contrario enviar Environment Request[Lookup[identifier’] customer’]. Lo anterior se basa en un actor EmptyEnvironmentque, cuando lo recibe Request[Lookup[identifier] customer], envía customer Thrown[NotFound[identifier]]. Cuando recibe una Bindsolicitud EmptyEnvironmentactúa como Environmentarriba.
Expresiones
El lenguaje de programación prototipo tiene expresiones de los siguientes tipos:
- Cuando Request[Eval[environment] customer]se reciba, envíe environmentRequest[Lookup[
] customer]
- enviar
ón> - Cuando Request[Eval[environment] customer]se reciba, envíe dónde hay un nuevo actor de modo que
Request[Eval[environment] evalCustomer1]evalCustomer1 - cuando reciba la comunicación , envíe evalCustomer1Returned[theRecipient]
- Request[Eval[environment] evalCustomer2]donde hay un nuevo actor tal que evalCustomer2
- cuando reciba la comunicación , envíela . evalCustomer2Returned[theCommunication]theRecipienttheCommunication
. - Cuando Request[Eval[environment] customer]se reciba, envíelo de manera que
Request[Eval[environment] evalCustomer1] - cuando reciba la comunicación , envíela de manera que evalCustomer1Returned[theRecipient]
Request[Eval[environment] evalCustomer2] - cuando reciba la comunicación , envíe evalCustomer2Returned[theMessage]theRecipient
- Request[theMessage customer]
- receptor ...
ón>i ón>i ... - Cuando Request[Eval[environment] customer]se reciba, envíe customerun nuevo actor de theReceivermodo que
- cuando theReceiverreciba una comunicación com, cree un bindingCustomerentorno nuevo y envíe
- Request[Bind[
i com] bindingCustomer] y - si bindingCustomerrecibe Returned[environment’], envíe
i - Request[Eval[environment’]]
- de lo contrario, si bindingCustomerrecibe Thrown[...], intente
i+1
- comportamiento ...
ón>i ón>i ... - Cuando Request[Eval[environment] customer]se reciba, envíe al cliente un nuevo actor de theReceivermodo que
- cuando theReceiverreciba Request[message customer’], cree uno nuevo bindingCustomery envíe environment
- Request[bind[
i message] customer’] y- si bindingCustomerrecibe Returned[environment’], envíe
i - Request[Eval[environment’] customer’]
- de lo contrario, si bindingCustomerrecibe Thrown[...], intente
i+1
- si bindingCustomerrecibe Returned[environment’], envíe
- {
ón>1 , ón>2 } - Cuando Request[Eval[environment] customer]se reciba, envíe y envíe simultáneamente .
1 Request[Eval[environment]]2 Request[Eval[environment]] customer]
- let
= value inbody - Cuando message[Eval[environment] customer]se reciba, cree una nueva evalCustomery envíe
value - Request[Eval[environment] evalCustomer1.
- Cuando evalCustomerreciba Returned[theValue], cree un nuevo bindingCustomery envíe environment
- Request[bind[
theValue] bindingCustomer] - Cuando bindingCustomerreciba Returned[environment’], envíe
body Request[Eval[environment’] customer]
- serializador
ón> - Cuando Request[Eval[environment] customer]se recibe, luego envía customerReturned[theSerializer]donde theSerializeres un nuevo actor de modo que las comunicaciones enviadas theSerializerse procesen en orden FIFO con un comportamiento Actor que es inicialmente
.Eval[environment] y - Cuando la comunicación comsea recibida por theSerializer, envíe el comportamiento Actor Request[com customer’]donde customer’hay un nuevo actor tal que
- when customer’recibe, Returned[theNextBehavior]entonces theNextBehaviorse utiliza como actor de comportamiento para la siguiente comunicación recibida por theSerializer.
Programa de ejemplo
Un programa de ejemplo para una celda de almacenamiento simple que puede contener cualquier dirección de actor es el siguiente:
- Celda ≡
- receptor
- Solicitar [Crear cliente [inicial]]
- enviar cliente devuelto [ serializador ReadWrite (inicial)]
- Solicitar [Crear cliente [inicial]]
- receptor
El programa anterior que crea una celda de almacenamiento hace uso del comportamiento ReadWrite que se define de la siguiente manera:
- ReadWrite (contenido) ≡
- comportamiento
- Solicitar [leer [] cliente]
- { enviar cliente devuelto [contenido], lectura y escritura (contenido)}
- Solicitar [escribir [x] cliente]
- { enviar cliente devuelto [], lectura y escritura (x)}
- Solicitar [leer [] cliente]
- comportamiento
Tenga en cuenta que el comportamiento anterior es canalizado, es decir, el comportamiento podría seguir procesando un mensaje de lectura o escritura anterior mientras procesa un mensaje de lectura o escritura posterior. Por ejemplo, la siguiente expresión crea una celda x con contenido inicial 5 y luego simultáneamente escribe en él con los valores 7 y 9.
- let 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.
Ver también
Referencias
- Henry Baker y Carl Hewitt The Incremental Garbage Collection of Processes Proceedings of the Symposium on Artificial Intelligence Programming Languages. Avisos SIGPLAN 12, agosto de 1977.
- Peter Bishop Espacio de direcciones muy grande Sistemas informáticos extensibles modularmente MIT EECS Disertación de doctorado. Junio de 1977.
- Henry Baker. Actor Sistemas de Computación en Tiempo Real MIT EECS Tesis Doctoral. Enero de 1978.
- Carl Hewitt y Russ Atkinson. Técnicas de especificación y prueba para serializadores IEEE Journal on Software Engineering. Enero de 1979.
- Ken Kahn. Una teoría computacional de la animación MIT EECS Tesis doctoral. Agosto de 1979.
- Carl Hewitt, Beppe Attardi y Henry Lieberman. Delegación en las actas de aprobación de mensajes de la Primera Conferencia Internacional sobre Sistemas Distribuidos Huntsville, AL. Octubre de 1979.
- Bill Kornfeld y Carl Hewitt. La metáfora de la comunidad científica Transacciones IEEE sobre sistemas, hombre y cibernética. Enero de 1981.
- Henry Lieberman. Pensar en muchas cosas a la vez sin confundirse: paralelismo en el memorando 626 de IA del MIT del acto 1, mayo de 1981.
- Henry Lieberman. A Preview of Act 1 MIT AI memo 625. Junio de 1981.
- Bill Kornfeld. Paralelismo en la resolución de problemas MIT EECS Tesis doctoral. Agosto de 1981.
- Daniel Theriault. A Primer for the Act-1 Language MIT AI memo 672. 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 de la Ley 2 Informe técnico de IA del MIT 728. Junio de 1983.
- Henry Lieberman. Un simulador orientado a objetos para la Conferencia Apiary de la Asociación Estadounidense de Inteligencia Artificial, Washington, DC, agosto de 1983.
- Carl Hewitt y Henry Lieberman. Design Issues in Parallel Architecture for Artificial Intelligence MIT AI memo 750. Nov. 1983.
- Charles Seitz. El Cubo Cósmico CACM. Enero de 1985.
- Carl Manning. Viajero: el actor observatorio ECOOP 1987. También aparece en Lecture Notes in Computer Science, vol. 276.
- Carl Manning ,. Acore: El diseño de un lenguaje de actor principal y su tesis de maestría de compilación . MIT EECS. Maiy 1987.
- William Athas y Charles Seitz Multicomputadoras: computadoras concurrentes de paso de mensajes IEEE Computer Agosto de 1988.
- William Athas y Nanette Boden Cantor: un sistema de programación de actores para la informática científica en las actas del taller de NSF sobre programación concurrente basada en objetos. 1988. Edición especial de avisos SIGPLAN.
- Jean-Pierre Briot. De los objetos a los 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 de 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 guardado: ¿son deductivos y lógicos? en Inteligencia Artificial en el MIT, vol. 2. MIT Press 1991.
- Carl Hewitt y Jeff Inman. DAI Betwixt y entre: de "agentes inteligentes" a la ciencia de sistemas abiertos Transacciones IEEE sobre sistemas, hombre y cibernética. Noviembre / diciembre 1991.
- William Dally y col. El procesador basado en 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. Protocolo simple de acceso a objetos (SOAP) 1.1 W3C Nota. Mayo de 2000.
- Edward A. Lee y Stephen Neuendorffer (junio de 2004). "Clases y Subclases en Diseño Orientado al Actor". Doctor. Disertación - resumen extendido. Conferencia sobre Métodos y Modelos Formales de Codificación (MEMOCODE). CiteSeerX 10.1.1.9.6762 . Cite journal requiere
|journal=
( ayuda ) - Carl Hewitt. La repetida desaparición de la programación lógica y por qué se reencarnará Lo que salió mal 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.