Articulo de referencia

Actor y modelo

El modelo de actores en informática es un modelo matemático de computación concurrente que considera al actor como el componente básico de dicha computación. En respuesta a un m...

El modelo de actores en informática es un modelo matemático de computación concurrente que considera al actor como el componente básico de dicha computación. En respuesta a un mensaje recibido, un actor puede: tomar decisiones locales, crear más actores, enviar más mensajes y determinar cómo responder al siguiente mensaje recibido. Los actores pueden modificar su propio estado privado , pero solo pueden afectarse entre sí indirectamente mediante mensajes (eliminando la necesidad de sincronización basada en bloqueos ).

El modelo de actores se originó en 1973. [ 1 ] Se ha utilizado tanto como marco para la comprensión teórica de la computación como base teórica para varias implementaciones prácticas de sistemas concurrentes . La relación del modelo con otros trabajos se analiza en el modelo de actores y los cálculos de procesos .

Historia

Según Carl Hewitt , a diferencia de los modelos de computación anteriores, el modelo de actor se inspiró en la física , incluyendo la relatividad general y la mecánica cuántica . También recibió influencias de los lenguajes de programación Lisp y Simula , las primeras versiones de Smalltalk , los sistemas basados ​​en capacidades y la conmutación de paquetes .

Su desarrollo fue "motivado por la perspectiva de máquinas de computación altamente paralelas que consisten en docenas, cientos o incluso miles de microprocesadores independientes , cada uno con su propia memoria local y procesador de comunicaciones , que se comunican a través de una red de comunicaciones de alto rendimiento ". [ 2 ] Desde entonces, la llegada de la concurrencia masiva a través de arquitecturas de computadoras multinúcleo y manycore ha reavivado el interés en el modelo de actor.

Tras la publicación de Hewitt, Bishop y Steiger en 1973, Irene Greif desarrolló una semántica operacional para el modelo de actor como parte de su investigación doctoral . [ 3 ] Dos años después, Henry Baker y Hewitt publicaron un conjunto de leyes axiomáticas para sistemas de actores. [ 4 ] [ 5 ] Otros hitos importantes incluyen la disertación de William Clinger de 1981 que introdujo una semántica denotacional basada en dominios de poder [ 2 ] y la disertación de Gul Agha de 1985 que desarrolló aún más un modelo semántico basado en transiciones complementario al de Clinger. [ 6 ] Esto dio como resultado el desarrollo completo de la teoría del modelo de actor .

El trabajo principal de implementación de software fue realizado por Russ Atkinson, Giuseppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman , Carl Manning, Tom Reinhardt, Richard Steiger y Dan Theriault en el Grupo de Semántica de Paso de Mensajes del Instituto Tecnológico de Massachusetts (MIT). Grupos de investigación liderados por Chuck Seitz en el Instituto Tecnológico de California (Caltech) y Bill Dally en el MIT construyeron arquitecturas informáticas que desarrollaron aún más el paso de mensajes en el modelo. Véase Implementación del modelo Actor .

Se han realizado investigaciones sobre el modelo del actor en el Instituto Tecnológico de California , el Laboratorio Tokoro de la Universidad de Kioto , la Corporación de Microelectrónica y Tecnología Informática (MCC), el Laboratorio de Inteligencia Artificial del MIT , SRI , la Universidad de Stanford , la Universidad de Illinois en Urbana-Champaign , [ 7 ] la Universidad Pierre y Marie Curie (Universidad de París 6), la Universidad de Pisa , el Laboratorio Yonezawa de la Universidad de Tokio , el Centrum Wiskunde & Informatica (CWI) y otros lugares.

Conceptos fundamentales

El modelo de actores adopta la filosofía de que todo es un actor . Esto es similar a la filosofía de que todo es un objeto, utilizada por algunos lenguajes de programación orientados a objetos .

Un actor es una entidad computacional que, en respuesta a un mensaje que recibe, puede simultáneamente:

  • enviar un número finito de mensajes a otros actores;
  • crear un número finito de nuevos actores;
  • designa el comportamiento que se utilizará para el siguiente mensaje que reciba.

No existe una secuencia preestablecida para las acciones anteriores y podrían llevarse a cabo en paralelo.

El desacoplamiento del remitente de las comunicaciones enviadas fue un avance fundamental del modelo de actor que permitió la comunicación asíncrona y las estructuras de control como patrones de paso de mensajes . [ 8 ]

Los destinatarios de los mensajes se identifican mediante una dirección, a veces llamada "dirección postal". Por lo tanto, un actor solo puede comunicarse con aquellos actores cuyas direcciones posee. Puede obtenerlas a partir de un mensaje que recibe o si la dirección corresponde a un actor que él mismo ha creado.

El modelo de actores se caracteriza por la concurrencia inherente de los cálculos dentro y entre los actores, la creación dinámica de actores, la inclusión de las direcciones de los actores en los mensajes y la interacción únicamente a través del paso directo y asíncrono de mensajes , sin ninguna restricción en el orden de llegada de los mensajes.

Sistemas formales

A lo largo de los años, se han desarrollado varios sistemas formales diferentes que permiten razonar sobre sistemas en el modelo de actores. Estos incluyen:

También existen formalismos que no son totalmente fieles al modelo de actor, ya que no formalizan la entrega garantizada de mensajes, incluidos los siguientes (véase Intentos de relacionar la semántica de los actores con el álgebra y la lógica lineal ):

Aplicaciones

El modelo de actores puede utilizarse como marco para modelar, comprender y razonar sobre una amplia gama de sistemas concurrentes . [ 15 ] Por ejemplo:

  • El correo electrónico ( email ) puede modelarse como un sistema de actores. Las cuentas se modelan como actores y las direcciones de correo electrónico como direcciones de actores.
  • Los servicios web pueden modelarse como actores, con los puntos finales del Protocolo simple de acceso a objetos ( SOAP ) modelados como direcciones de actor.
  • Los objetos con bloqueos ( por ejemplo , en Java y C# ) pueden modelarse como un serializador , siempre que sus implementaciones permitan la llegada continua de mensajes (quizás almacenándolos en una cola interna ). Un serializador es un tipo importante de actor definido por la propiedad de estar continuamente disponible para la llegada de nuevos mensajes; se garantiza la llegada de cada mensaje enviado a un serializador. [ 16 ]
  • La notación de pruebas y control de pruebas ( TTCN ), tanto TTCN-2 como TTCN-3 , sigue de cerca el modelo de actores. En TTCN, un actor es un componente de prueba: un componente de prueba paralelo (PTC) o un componente de prueba principal (MTC). Los componentes de prueba pueden enviar y recibir mensajes de socios remotos (componentes de prueba pares o interfaz del sistema de prueba), estos últimos identificados por su dirección. Cada componente de prueba tiene un árbol de comportamiento asociado; los componentes de prueba se ejecutan en paralelo y pueden ser creados dinámicamente por componentes de prueba padres. Las construcciones de lenguaje integradas permiten definir acciones que se deben realizar cuando se recibe un mensaje esperado de la cola de mensajes interna, como enviar un mensaje a otra entidad par o crear nuevos componentes de prueba.

Semántica de paso de mensajes

El modelo de actor trata sobre la semántica del paso de mensajes .

Controversia sobre el no determinismo ilimitado

Podría decirse que los primeros programas concurrentes fueron los manejadores de interrupciones . Durante su funcionamiento normal, un ordenador necesitaba recibir información del exterior (caracteres de un teclado, paquetes de una red, etc. ). Así pues, cuando llegaba la información, la ejecución del ordenador se interrumpía y se ejecutaba un código especial (llamado manejador de interrupciones) para almacenar la información en un búfer de datos , desde donde podía recuperarse posteriormente.

A principios de la década de 1960, se empezaron a usar interrupciones para simular la ejecución concurrente de varios programas en un procesador. [ 17 ] La concurrencia con memoria compartida dio lugar al problema del control de concurrencia . Originalmente, este problema se concibió como uno de exclusión mutua en una sola computadora. Edsger Dijkstra desarrolló semáforos y, posteriormente, entre 1971 y 1973, [ 18 ] Tony Hoare [ 19 ] y Per Brinch Hansen [ 20 ] desarrollaron monitores para resolver el problema de la exclusión mutua. Sin embargo, ninguna de estas soluciones proporcionó una construcción de lenguaje de programación que encapsulara el acceso a los recursos compartidos. Esta encapsulación se logró más tarde mediante la construcción serializadora ([Hewitt y Atkinson 1977, 1979] y [Atkinson 1980]).

Los primeros modelos de computación ( por ejemplo , máquinas de Turing , postproducciones, cálculo lambda , etc. ) se basaban en las matemáticas y utilizaban un estado global para representar un paso computacional (generalizado posteriormente en [McCarthy y Hayes 1969] y [Dijkstra 1976], véase Ordenamientos de eventos frente a estado global ). Cada paso computacional iba de un estado global de la computación al siguiente. El enfoque del estado global se continuó en la teoría de autómatas para máquinas de estados finitos y máquinas de pila descendente , incluidas sus versiones no deterministas . Dichos autómatas no deterministas tienen la propiedad de no determinismo acotado ; es decir, si una máquina siempre se detiene al comenzar en su estado inicial, entonces hay un límite en el número de estados en los que se detiene.

Edsger Dijkstra desarrolló aún más el enfoque de estado global no determinista. El modelo de Dijkstra dio lugar a una controversia sobre el no determinismo ilimitado (también llamado indeterminación ilimitada ), una propiedad de la concurrencia por la cual la cantidad de retraso en el servicio de una solicitud puede volverse ilimitada como resultado del arbitraje de la contención por recursos compartidos, aunque garantizando que la solicitud finalmente será atendida . Hewitt argumentó que el modelo de actor debería proporcionar la garantía de servicio. En el modelo de Dijkstra, aunque podría haber una cantidad ilimitada de tiempo entre la ejecución de instrucciones secuenciales en una computadora, un programa (paralelo) que comenzó en un estado bien definido solo podría terminar en un número limitado de estados [Dijkstra 1976]. En consecuencia, su modelo no podía proporcionar la garantía de servicio. Dijkstra argumentó que era imposible implementar el no determinismo ilimitado.

Hewitt argumentó lo contrario: no hay límite que se pueda establecer sobre cuánto tiempo tarda un circuito computacional llamado árbitro en estabilizarse (véase metaestabilidad (electrónica) ). [ 21 ] Los árbitros se utilizan en computadoras para lidiar con la circunstancia de que los relojes de las computadoras operan de manera asíncrona con respecto a la entrada externa, por ejemplo , entrada de teclado, acceso a disco, entrada de red, etc. Por lo tanto, podría tomar un tiempo ilimitado para que se reciba un mensaje enviado a una computadora y, mientras tanto, la computadora podría pasar por un número ilimitado de estados.

El modelo de actor presenta un no determinismo ilimitado que fue capturado en un modelo matemático por Will Clinger utilizando la teoría de dominios . [ 2 ] En el modelo de actor, no hay un estado global.

Comunicación directa y asincronía

En el modelo de actores, los mensajes no necesariamente se almacenan en búfer. Esto representó una ruptura radical con los enfoques anteriores de los modelos de computación concurrente. La falta de almacenamiento en búfer generó mucha confusión durante el desarrollo del modelo de actores y sigue siendo un tema controvertido. Algunos investigadores argumentaron que los mensajes se almacenan en el "éter" o el "entorno". Además, en el modelo de actores, los mensajes simplemente se envían (como paquetes en IP ); no se requiere un protocolo de enlace síncrono con el receptor.

La creación de actores más las direcciones en los mensajes implica una topología variable.

Una evolución natural del modelo de actores fue permitir el uso de direcciones en los mensajes. Influenciado por las redes de conmutación de paquetes [1961 y 1964], Hewitt propuso el desarrollo de un nuevo modelo de computación concurrente en el que las comunicaciones no tendrían campos obligatorios: podrían estar vacías. Por supuesto, si el remitente de una comunicación deseaba que el destinatario tuviera acceso a direcciones que no poseía, la dirección debía enviarse en la comunicación.

Por ejemplo, un actor podría necesitar enviar un mensaje a un actor receptor del cual espera recibir una respuesta, pero esta respuesta será gestionada por un tercer componente actor configurado para recibirla y procesarla (por ejemplo, un actor diferente que implemente el patrón observador ). El actor original podría lograr esto enviando una comunicación que incluya el mensaje que desea enviar, junto con la dirección del tercer actor que gestionará la respuesta. Este tercer actor que gestionará la respuesta se denomina reanudación (a veces también llamado continuación o marco de pila ). Cuando el actor receptor esté listo para enviar una respuesta, la envía a la dirección del actor de reanudación que se incluyó en la comunicación original.

Así pues, la capacidad de los actores para crear nuevos actores con los que puedan intercambiar comunicaciones, junto con la capacidad de incluir las direcciones de otros actores en los mensajes, otorga a los actores la capacidad de crear y participar en relaciones topológicas arbitrariamente variables entre sí, de forma similar a como los objetos en Simula y otros lenguajes orientados a objetos también pueden componerse relacionalmente en topologías variables de objetos que intercambian mensajes.

Intrínsecamente concurrentes

A diferencia del enfoque anterior basado en la composición de procesos secuenciales, el modelo de actor se desarrolló como un modelo inherentemente concurrente. En el modelo de actor, la secuencialidad era un caso especial derivado de la computación concurrente, como se explica en la teoría del modelo de actor .

No hay ningún requisito sobre el orden de llegada de los mensajes.

Hewitt argumentó en contra de agregar el requisito de que los mensajes deben llegar en el orden en que se envían al actor. Si se desea un orden de mensajes de salida, se puede modelar mediante un actor de cola que proporcione esta funcionalidad. Dicho actor de cola pondría en cola los mensajes que llegan para que puedan recuperarse en orden FIFO . Por lo tanto, si un actor Xenvió un mensaje M1a un actor Yy luego Xenvió otro mensaje M2a Y, no hay ningún requisito de que M1llegue a Yantes que M2.

En este sentido, el modelo de actor refleja los sistemas de conmutación de paquetes , que no garantizan que los paquetes se reciban en el orden en que se enviaron. Al no ofrecer esta garantía de orden de entrega, la conmutación de paquetes puede almacenar paquetes en búfer, usar múltiples rutas para enviarlos, reenviar paquetes dañados y ofrecer otras optimizaciones.

Por ejemplo, los actores pueden procesar mensajes en paralelo. Esto significa que, durante el procesamiento de un mensaje M1, un actor puede definir el comportamiento para procesar el siguiente y, de hecho, comenzar a procesar otro M2antes de haber terminado el anterior M1. El hecho de que un actor pueda procesar mensajes en paralelo no implica que deba hacerlo. El procesamiento en paralelo de un mensaje es una cuestión de diseño. ¿Cómo podría un observador externo saber si un actor está procesando un mensaje en paralelo? La definición de actor no genera ambigüedad en la posibilidad de procesamiento en paralelo. Por supuesto, es posible optimizar el procesamiento en paralelo de forma incorrecta en algunas implementaciones, lo que podría provocar un comportamiento inesperado.

Localidad

Otra característica importante del modelo de actor es la localidad.

La localidad implica que, al procesar un mensaje, un actor solo puede enviar mensajes a las direcciones que recibe en el mensaje, a las direcciones que ya tenía antes de recibirlo y a las direcciones de los actores que crea durante el procesamiento. (Véase también Síntesis de direcciones de actores ).

Además, la localidad implica que no hay cambios simultáneos en múltiples ubicaciones. De esta manera, se diferencia de otros modelos de concurrencia, por ejemplo , el modelo de red de Petri, en el que los tokens se eliminan simultáneamente de múltiples ubicaciones y se colocan en otras.

Composición de sistemas de actores

La idea de componer sistemas de actores en sistemas más grandes es un aspecto importante de la modularidad que se desarrolló en la tesis doctoral de Gul Agha, [ 6 ] y que posteriormente desarrollaron Gul Agha, Ian Mason, Scott Smith y Carolyn Talcott . [ 9 ]

Comportamientos

Una innovación clave fue la introducción del comportamiento, especificado como una función matemática, para expresar lo que hace un actor al procesar un mensaje, incluyendo la especificación de un nuevo comportamiento para procesar el siguiente mensaje que llegue. Los comportamientos proporcionaron un mecanismo para modelar matemáticamente el intercambio en la concurrencia.

Los comportamientos también liberaron al modelo de actores de los detalles de implementación, por ejemplo , el intérprete de flujo de tokens de Smalltalk-72. Sin embargo, la implementación eficiente de los sistemas descritos por el modelo de actores requiere una optimización exhaustiva . Consulte la sección "Implementación del modelo de actores" para obtener más detalles.

Modelado de otros sistemas de concurrencia

Otros sistemas de concurrencia ( por ejemplo , cálculos de procesos ) pueden modelarse en el modelo de actor utilizando un protocolo de confirmación de dos fases . [ 22 ]

Teorema de representación computacional

Existe un teorema de representación computacional en el modelo de actor para sistemas que son cerrados en el sentido de que no reciben comunicaciones del exterior. La notación matemática denotada por un sistema cerradoS{\displaystyle {\mathtt {S}}}se construye a partir de un comportamiento inicialS{\displaystyle \bot _{\mathtt {S}}}y una función de aproximación del comportamientopagrogramormissionorteS.{\displaystyle \mathbf {progresión} _ {\mathtt {S}}.}Estos obtienen aproximaciones cada vez mejores y construyen una denotación (significado) paraS{\displaystyle {\mathtt {S}}}de la siguiente manera [Hewitt 2008; Clinger 1981]:

DminorteotmiSlímiteipagrogramormissionorteSi(S){\displaystyle \mathbf {Denotar} _{\mathtt {S}}\equiv \lim _{i\to \infty }\mathbf {progresión} _ {{\mathtt {S}}^{i}}(\bot _{\mathtt {S}})}

De este modo,S{\displaystyle {\mathtt {S}}}puede caracterizarse matemáticamente en términos de todos sus posibles comportamientos (incluidos aquellos que implican no determinismo ilimitado). AunqueDminorteotmiS{\displaystyle \mathbf {Denote} _{\mathtt {S}}}no es una implementación deS{\displaystyle {\mathtt {S}}}, puede utilizarse para demostrar una generalización de la tesis de Church-Turing-Rosser-Kleene [Kleene 1943]:

Una consecuencia del teorema anterior es que un agente finito puede responder de forma no determinista con un número incontable de resultados diferentes.

Relación con la programación lógica

Una de las principales motivaciones para el desarrollo del modelo de actores fue comprender y abordar los problemas de estructura de control que surgieron durante el desarrollo del lenguaje de programación Planner . Una vez definido inicialmente el modelo de actores, un desafío importante fue comprender su potencial en relación con la tesis de Robert Kowalski de que "la computación puede subsumirse mediante la deducción". Hewitt argumentó que la tesis de Kowalski resultó ser falsa para la computación concurrente en el modelo de actores (véase Indeterminación en la computación concurrente ).

No obstante, se hicieron intentos por extender la programación lógica a la computación concurrente. Sin embargo, Hewitt y Agha [1991] afirmaron que los sistemas resultantes no eran deductivos en el siguiente sentido: los pasos computacionales de los sistemas de programación lógica concurrente no se derivan deductivamente de los pasos anteriores (véase Indeterminación en la computación concurrente ). Recientemente, la programación lógica se ha integrado en el modelo de actores de manera que se mantenga la semántica lógica. [ 21 ]

Migración

En el modelo de actores, la migración se refiere a la capacidad de los actores para cambiar de ubicación. Por ejemplo , en su tesis, Aki Yonezawa modeló una oficina de correos donde los clientes podían entrar, cambiar de ubicación durante su funcionamiento y salir. Un actor con capacidad de migración puede modelarse mediante un actor de ubicación que cambia cuando el actor migra. Sin embargo, la fidelidad de este modelo es controvertida y objeto de investigación.

Seguridad

La seguridad de los actores puede protegerse de las siguientes maneras:

Sintetizando las direcciones de los actores

Un aspecto delicado del modelo de actores es la capacidad de sintetizar la dirección de un actor. En algunos casos, se puede utilizar la seguridad para impedir la síntesis de direcciones (véase Seguridad ). Sin embargo, si la dirección de un actor es simplemente una cadena de bits, es evidente que se puede sintetizar, aunque puede resultar difícil o incluso imposible adivinarla si las cadenas de bits son lo suficientemente largas. SOAP utiliza una URL para la dirección de un punto final al que se puede acceder. Dado que una URL es una cadena de caracteres, es evidente que se puede sintetizar, aunque el cifrado puede hacer que sea prácticamente imposible adivinarla.

La síntesis de las direcciones de los actores se suele modelar mediante mapeo. La idea es utilizar un sistema de actores para realizar el mapeo a las direcciones reales de los actores. Por ejemplo, en un ordenador, la estructura de memoria se puede modelar como un sistema de actores que realiza el mapeo. En el caso de las direcciones SOAP , se modela el DNS y el resto del mapeo de URL .

Contrasta con otros modelos de concurrencia por paso de mensajes.

El trabajo inicial publicado por Robin Milner sobre concurrencia [ 23 ] también fue notable porque no se basaba en la composición de procesos secuenciales. Su trabajo difería del modelo de actor porque se basaba en un número fijo de procesos de topología fija que comunicaban números y cadenas mediante comunicación síncrona. El modelo original de procesos secuenciales comunicantes (CSP) [ 24 ] publicado por Tony Hoare difería del modelo de actor porque se basaba en la composición paralela de un número fijo de procesos secuenciales conectados en una topología fija, y que se comunicaban mediante paso de mensajes síncrono basado en nombres de procesos (véase Modelo de actor e historia de los cálculos de procesos ). Las versiones posteriores de CSP abandonaron la comunicación basada en nombres de procesos en favor de la comunicación anónima a través de canales, un enfoque también utilizado en el trabajo de Milner sobre el cálculo de sistemas comunicantes (CCS) y el π-cálculo .

Estos primeros modelos de Milner y Hoare presentaban la propiedad de no determinismo acotado. El CSP teórico moderno ([Hoare 1985] y [Roscoe 2005]) proporciona explícitamente no determinismo acotado.

Las redes de Petri y sus extensiones (por ejemplo, las redes de Petri coloreadas) son como los actores en el sentido de que se basan en el paso de mensajes asíncrono y el no determinismo ilimitado, mientras que se parecen a los primeros CSP en el sentido de que definen topologías fijas de pasos de procesamiento elementales (transiciones) y repositorios de mensajes (lugares).

Influencia

El modelo del actor ha influido tanto en el desarrollo teórico como en el desarrollo práctico de software.

Teoría

El modelo del actor ha influido en el desarrollo del cálculo π y los cálculos de procesos subsiguientes . En su conferencia de Turing, Robin Milner escribió: [ 25 ]

Ahora bien, el cálculo lambda puro se construye con solo dos tipos de elementos: términos y variables. ¿Podemos lograr la misma economía para un cálculo de procesos? Carl Hewitt, con su modelo de actores, respondió a este desafío hace mucho tiempo; declaró que un valor, un operador sobre valores y un proceso deberían ser todos del mismo tipo: un actor.

Este objetivo me impresionó, porque implica homogeneidad y completitud de la expresión... Pero pasó mucho tiempo antes de que pudiera ver cómo alcanzar el objetivo en términos de cálculo algebraico...

Así pues, siguiendo el espíritu de Hewitt, nuestro primer paso es exigir que todas las cosas designadas por términos o a las que se accede mediante nombres —valores, registros, operadores, procesos, objetos— sean todas del mismo tipo; todas deberían ser procesos.

Práctica

El modelo de actores ha tenido una gran influencia en la práctica comercial. Por ejemplo, Twitter ha utilizado actores para la escalabilidad. [ 26 ] Asimismo, Microsoft ha utilizado el modelo de actores en el desarrollo de su biblioteca de agentes asíncronos. [ 27 ] Existen otras bibliotecas de actores que se enumeran en la sección de bibliotecas y marcos de actores que aparece a continuación.

Problemas abordados

Según Hewitt [2006], el modelo de actor aborda cuestiones de arquitectura informática y de comunicaciones, lenguajes de programación concurrentes y servicios web , incluyendo lo siguiente:

  • Escalabilidad : el reto de aumentar la concurrencia tanto a nivel local como no local.
  • Transparencia : salvar la brecha entre la concurrencia local y la no local. La transparencia es actualmente un tema controvertido. Algunos investigadores han defendido una separación estricta entre la concurrencia local mediante lenguajes de programación concurrentes (p. ej., Java y C# ) y la concurrencia no local mediante SOAP para servicios web . Esta separación estricta genera falta de transparencia, lo que causa problemas cuando es deseable o necesario alternar entre el acceso local y el no local a los servicios web (véase Computación distribuida ).
  • Inconsistencia : la inconsistencia es la norma porque todos los grandes sistemas de conocimiento sobre las interacciones entre sistemas de información y humanos son inconsistentes. Esta inconsistencia se extiende a la documentación y las especificaciones de grandes sistemas (por ejemplo, el software Microsoft Windows, etc.), que presentan inconsistencias internas.

Muchas de las ideas introducidas en el modelo de actores ahora también se aplican en sistemas multiagente por estas mismas razones [Hewitt 2006b 2007b]. La diferencia clave radica en que los sistemas de agentes (en la mayoría de las definiciones) imponen restricciones adicionales a los actores, generalmente exigiéndoles que utilicen compromisos y objetivos.

Programación con actores

Varios lenguajes de programación utilizan el modelo de actores o alguna variación del mismo. Estos lenguajes incluyen:

Lenguajes de programación de actores primitivos

Lenguajes de programación de actores posteriores

Bibliotecas y marcos de actores

También se han implementado bibliotecas o marcos de trabajo de actores para permitir la programación al estilo de actores en lenguajes que no los tienen integrados. Algunos de estos marcos de trabajo son:

Véase también

Referencias

  1. Hewitt, Carl ; Bishop, Peter; Steiger, Richard (1973). "Un formalismo de actor modular universal para la inteligencia artificial". IJCAI.{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  2. 1 2 3 4 Clinger, William (junio de 1981). Fundamentos de la semántica de actores (tesis doctoral). Disertación doctoral en matemáticas. MIT. hdl : 1721.1/6935 .
  3. 1 2 Greif, Irene (agosto de 1975). Semántica de los procesos paralelos comunicantes (tesis doctoral). Disertación doctoral de EECS. MIT.
  4. 1 2 Baker, Henry ; Hewitt, Carl (agosto de 1977). "Leyes para la comunicación de procesos paralelos". IFIP.{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  5. "Leyes para la comunicación de procesos paralelos" (PDF) . 10 de mayo de 1977. Archivado (PDF) del original el 24 de junio de 2016. Recuperado el 11 de junio de 2014 .
  6. 1 2 3 Agha, Gul (1986). Actors: A Model of Concurrent Computation in Distributed Systems (PhD thesis). Doctoral Dissertation. MIT Press. hdl : 1721.1/6952 .
  7. "Inicio" . Osl.cs.uiuc.edu. Archivado del original el 22/02/2013 . Consultado el 02/12/2012 .
  8. Carl Hewitt. Visualización de las estructuras de control como patrones de transmisión de mensajes. Revista de Inteligencia Artificial. Junio ​​de 1977.
  9. 1 2 Gul Agha; Ian Mason; Scott Smith; Carolyn Talcott (enero de 1993). "Una base para la computación de actores". Journal of Functional Programming .
  10. Carl Hewitt (27 de abril de 2006). "¿Qué es el compromiso? Físico, organizacional y social" (PDF) . Archivado (PDF) del original el 11 de febrero de 2021. Consultado el 26 de mayo de 2006 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  11. Mauro Gaspari; Gianluigi Zavattaro (mayo de 1997). "Un álgebra de actores" (PDF) . "Métodos formales para sistemas distribuidos abiertos basados ​​​​en objetos" . Informe Técnico UBLCS-97-4. Universidad de Bolonia. págs. 3 a 18. doi : 10.1007/978-0-387-35562-7_2 . ISBN  978-1-4757-5266-3. Archivado (PDF) del original el 26-07-2018 . Recuperado el 08-04-2019 .
  12. M. Gaspari; G. Zavattaro (1999). "Un álgebra de actores". Métodos formales para sistemas abiertos basados ​​en objetos.{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  13. Gul Agha ; Prasanna Thati (2004). "Una teoría algebraica de actores y su aplicación a un lenguaje simple basado en objetos" (PDF) . De OO a FM (Dahl Festschrift) LNCS 2635. Archivado del original (PDF) el 20 de abril de 2004.{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  14. John Darlington; YK Guo (1994). "Formalización de actores en lógica lineal". Conferencia internacional sobre sistemas de información orientados a objetos.{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  15. "¿Qué es el modelo actor y cuándo deberías usarlo?" . Matt Ferderer . Archivado del original el 25/08/2021 . Consultado el 25/08/2021 .
  16. Cheung, Leo (25 de julio de 2017). "Por qué Akka y el modelo de actor destacan en las aplicaciones de IoT" . InfoWorld . Archivado del original el 25 de agosto de 2021. Consultado el 25 de agosto de 2021 .
  17. Hansen, Per Brinch (2002). Los orígenes de la programación concurrente: de los semáforos a las llamadas a procedimientos remotos . Springer. ISBN 978-0-387-95401-1.
  18. Hansen, Per Brinch (1996). "Monitores y Pascal concurrente: una historia personal". Communications of the ACM : 121–172 .
  19. Hoare, Tony (octubre de 1974). "Monitores: un concepto de estructuración de sistemas operativos" . Communications of the ACM . 17 (10): 549– 557. doi : 10.1145/355620.361161 . S2CID 1005769 . 
  20. Hansen, Per Brinch (julio de 1973). Principios de sistemas operativos . Prentice-Hall.
  21. 1 2 Hewitt, Carl (2012). "¿Qué es la computación? Modelo del actor versus modelo de Turing". En Zenil, Hector (ed.). Un universo computable: comprender la computación y explorar la naturaleza como computación. Dedicado a la memoria de Alan M. Turing en el centenario de su nacimiento . World Scientific Publishing Company.
  22. Frederick Knabe. Un protocolo distribuido para la comunicación basada en canales con elección PARLE 1992 Archivado el 31-08-2017 en Wayback Machine .
  23. Robin Milner. Procesos: Un modelo matemático de agentes computacionales en el Coloquio de Lógica de 1973.
  24. CAR Hoare. Comunicación de procesos secuenciales CACM. Agosto de 1978.
  25. Milner, Robin (1993). "Elementos de interacción" . Communications of the ACM . 36 : 78–89 . doi : 10.1145/151233.151240 .
  26. "Cómo Twitter está escalando « Blog de Waiming Mok" . Waimingmok.wordpress.com. 27 de junio de 2009. Archivado del original el 5 de febrero de 2021. Consultado el 2 de diciembre de 2012 . 
  27. " Programación basada en actores con la biblioteca de agentes asíncronos Archivado el 31/08/2017 en Wayback Machine " MSDN septiembre de 2010.
  28. Henry Lieberman (junio de 1981). "Un adelanto del acto 1". Memorando 625 del MIT AI. hdl : 1721.1/6350 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  29. Henry Lieberman (junio de 1981). "Pensar en muchas cosas a la vez sin confundirse: paralelismo en el acto 1". MIT AI memo 626. hdl : 1721.1/6351 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  30. Jean-Pierre Briot. Acttalk: Un marco para la programación concurrente orientada a objetos: diseño y experiencia. Segundo taller Francia-Japón. 1999. Archivado el 28 de junio de 2018 en Wayback Machine.
  31. Ken Kahn. Una teoría computacional de la animación. Archivado el 18 de agosto de 2017 en Wayback Machine. Tesis doctoral del MIT EECS. Agosto de 1979.
  32. William Athas y Nanette Boden Cantor: Un sistema de programación de actores para computación científica Archivado el 8 de abril de 2019 en Wayback Machine en Actas del Taller de la NSF sobre Programación Concurrente Basada en Objetos. 1988. Número especial de SIGPLAN Notices.
  33. Darrell Woelk. Desarrollo de agentes InfoSleuth utilizando Rosette: un lenguaje basado en actores. Actas del taller CIKM '95 sobre agentes de información inteligentes. 1995.
  34. ^ Dedecker J., Van Cutsem T., Mostinckx S., D'Hondt T., De Meuter W. Programación orientada al ambiente en AmbientTalk. En "Actas de la 20ª Conferencia Europea sobre Programación Orientada a Objetos (ECOOP), Dave Thomas (Ed.), Lecture Notes in Computer Science Vol. 4067, págs. 230-254, Springer-Verlag.", 2006
  35. Darryl K. Taft (17 de abril de 2009). "Microsoft está preparando un nuevo lenguaje de programación paralela" . Eweek.com . Consultado el 2 de diciembre de 2012 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  36. "Humus" . Dalnefre.com. Archivado del original el 7 de febrero de 2021. Consultado el 2 de diciembre de 2012 .
  37. Brandauer, Stephan; et al. (2015). "Objetos paralelos para multinúcleos: Una mirada al lenguaje paralelo Encore". Métodos formales para programación multinúcleo . Springer International Publishing: 1–56 . 
  38. "El lenguaje poni" . Archivado del original el 4 de septiembre de 2018. Consultado el 21 de marzo de 2016 .
  39. Clebsch, Sylvan; Drossopoulou, Sophia; Blessing, Sebastian; McNeil, Andy (2015). «Deny capabilities for safe, fast actors». Proceedings of the 5th International Workshop on Programming Based on Actors, Agents, and Decentralized Control - AGERE! 2015 . pp. 1– 12. doi : 10.1145/2824815.2824816 . ISBN  9781450339018. S2CID 415745 . Por Sylvan Clebsch, Sophia Drossopoulou, Sebastian Blessing y Andy McNeil
  40. "El lenguaje P" . GitHub . 8 de marzo de 2019. Archivado del original el 15 de enero de 2021. Consultado el 1 de febrero de 2017 .
  41. "El lenguaje P#" . GitHub . 12 de marzo de 2019. Archivado del original el 23 de marzo de 2021. Consultado el 1 de febrero de 2017 .
  42. "clase Ractor" . Ruby-lang.org. Archivado del original el 2 de marzo de 2022. Consultado el 2 de marzo de 2022 .
  43. Varela, Carlos; Agha, Gul (2001). "Programación de sistemas abiertos reconfigurables dinámicamente con SALSA". ACM SIGPLAN Notices . 36 (12): 20– 34. doi : 10.1145/583960.583964 .
  44. Philipp Haller y Martin Odersky (septiembre de 2006). "Programación basada en eventos sin inversión de control" (PDF) . Actas de JMLC 2006. Archivado (PDF) del original el 9 de noviembre de 2020. Consultado el 5 de abril de 2007 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  45. Philipp Haller y Martin Odersky (enero de 2007). "Actores que unifican hilos y eventos" (PDF) . Informe técnico LAMP 2007. Archivado del original (PDF) el 7 de junio de 2011. Consultado el 10 de diciembre de 2007 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  46. "Guía del lenguaje Swift - Concurrencia" . Archivado del original el 1 de marzo de 2022. Consultado el 11 de marzo de 2022 .
  47. "acteur - 0.9.1· David Bonet · Crates.io" . crates.io. Archivado del original el 05-02-2021 . Recuperado el 16-04-2020 .
  48. Bulut, Mahmut (15 de diciembre de 2019). "Bastión en Crates.io" . Crates.io . Archivado del original el 5 de febrero de 2021. Consultado el 15 de diciembre de 2019 .
  49. "actix - 0.10.0· Rob Ede · Crates.io" . crates.io. Archivado del original el 14-05-2021 . Recuperado el 28-02-2021 .
  50. "Versiones · zakgof/actr · GitHub" . Github.com. Archivado del original el 26-10-2020 . Consultado el 16-04-2019 .
  51. ^ "Lanzamiento de Akka 2.6.20 · Akka" . Acká. 2022-09-06. Archivado desde el original el 24 de septiembre de 2022 . Consultado el 24 de septiembre de 2022 .
  52. "Preguntas frecuentes sobre la licencia de Akka | @lightbend" . Archivado del original el 22/09/2022 . Consultado el 24/09/2022 .
  53. Akka.NET v1.4.10 Versión estable GitHub - akkadotnet/akka.net: Puerto de los actores de Akka para .NET. , Akka.NET, 01/10/2020, archivado del original el 24/02/2021 , recuperado el 01/10/2020
  54. Apache Pekko (Graduado) , Fundación de Software Apache
  55. Srinivasan, Sriram; Alan Mycroft (2008). "Kilim: Actores con tipo de aislamiento para Java" (PDF) . Conferencia Europea sobre Programación Orientada a Objetos ECOOP 2008. Chipre. Archivado (PDF) del original el 28 de octubre de 2020. Recuperado el 25 de febrero de 2016 .
  56. "Versiones · kilim/kilim · GitHub" . Github.com. Archivado del original el 16-10-2020 . Consultado el 03-06-2019 .
  57. "Historial de confirmaciones · stevedekorte/ActorKit · GitHub" . Github.com . Consultado el 25 de febrero de 2016 .
  58. "Hackage: El repositorio de paquetes de Haskell" . Hackage . Consultado el 1 de mayo de 2024 .
  59. "CloudI: Una nube en el nivel más bajo · Actividad" . sourceforge.net . Consultado el 3 de enero de 2024 .
  60. "Etiquetas · GNOME/clutter · GitLab" . gitlab.gnome.org. Archivado del original el 3 de junio de 2019. Consultado el 3 de junio de 2019 .
  61. "Versiones · ncthbrt/nact · GitHub" . GitHub . Archivado del original el 27-11-2020 . Consultado el 03-06-2019 .
  62. "Cambios - retlang - Concurrencia basada en mensajes en .NET - Google Project Hosting" . Archivado del original el 24/11/2015 . Consultado el 25/02/2016 .
  63. "jetlang-0.2.9-bin.zip - jetlang - jetlang-0.2.9-bin.zip - Concurrencia basada en mensajes para Java - Google Project Hosting" . 14 de febrero de 2012. Archivado del original el 14 de enero de 2016. Consultado el 25 de febrero de 2016 .
  64. "GPars Releases" . GitHub. Archivado del original el 4 de septiembre de 2020. Consultado el 25 de febrero de 2016 .
  65. "Versiones · oosmos/oosmos · GitHub" . GitHub. Archivado del original el 13 de noviembre de 2020. Consultado el 3 de junio de 2019 .
  66. "Diseño y actores de Pulsar" . Archivado del original el 4 de julio de 2015.
  67. "Documentación de Pulsar" . Archivado del original el 26 de julio de 2013.
  68. "Cambios – Documentación de Pykka 2.0.0" . pykka.org. Archivado del original el 5 de febrero de 2021. Consultado el 3 de junio de 2019 .
  69. "Theron – Ashton Mason" . Archivado del original el 31 de marzo de 2019. Consultado el 29 de agosto de 2018 .
  70. "Theron - Versión 6.00.02 publicada" . Theron-library.com. Archivado del original el 16 de marzo de 2016. Consultado el 25 de febrero de 2016 .
  71. "Theron" . Theron-library.com. Archivado del original el 4 de marzo de 2016. Consultado el 25 de febrero de 2016 .
  72. "Lanzamientos · puniverse/quasar · GitHub" . GitHub . Archivado del original el 15-12-2020 . Consultado el 03-06-2019 .
  73. "Cambios - actor-cpp - Una implementación del modelo de actor para C++ - Google Project Hosting" . Archivado del original el 18/11/2015 . Consultado el 02/12/2012 .
  74. "Historial de confirmaciones · s4/s4 · Apache" . apache.org. Archivado del original el 6 de marzo de 2016. Consultado el 16 de enero de 2016 .
  75. "Versiones · actor-framework/actor-framework · GitHub" . Github.com. Archivado del original el 26-03-2021 . Consultado el 07-03-2020 .
  76. "celluloid | RubyGems.org | tu comunidad de alojamiento de gemas" . RubyGems.org. Archivado del original el 29/09/2020 . Consultado el 03/06/2019 .
  77. "Comunidad: Marco de Actores, revisión LV 2011 (versión 3.0.7)" . Decibel.ni.com. 23 de septiembre de 2011. Archivado del original el 13 de octubre de 2016. Consultado el 25 de febrero de 2016 .
  78. "Versiones · orbit/orbit · GitHub" . GitHub . Consultado el 3 de junio de 2019 .
  79. "QP Real-Time Embedded Frameworks & Tools - Explore Files at" . Sourceforge.net. Archivado del original el 24/02/2021 . Consultado el 03/06/2019 .
  80. "Versiones · Stiffstream/sobjectizer · GitHub" . GitHub. Archivado del original el 19 de octubre de 2020. Consultado el 11 de mayo de 2022 .
  81. "Versiones · basiliscos/cpp-rotor · GitHub" . GitHub. Archivado del original el 15 de septiembre de 2020. Consultado el 26 de enero de 2025 .
  82. "Versiones · dotnet/orleans · GitHub" . GitHub. Archivado del original el 4 de diciembre de 2020. Consultado el 21 de septiembre de 2022 .
  83. "FunctionalJava releases" . GitHub. Archivado del original el 15/01/2021 . Consultado el 23/08/2018 .

Lecturas adicionales

  • Gul Agha. Actors: A Model of Concurrent Computation in Distributed Systems. Archivado el 12 de noviembre de 2020 en Wayback Machine . MIT Press, 1985.
  • Paul Baran. Sobre redes de comunicaciones distribuidas. IEEE Transactions on Communications Systems . Marzo de 1964.
  • William A. Woods. Gramáticas de redes de transición para el análisis del lenguaje natural. Archivado el 3 de febrero de 2017 en Wayback Machine CACM. 1970.
  • Carl Hewitt. Incrustación procedimental del conocimiento en Planner Archivado el 5 de febrero de 2021 en Wayback Machine IJCAI 1971.
  • GM Birtwistle, Ole-Johan Dahl , B. Myhrhaug y Kristen Nygaard . SIMULA Begin Auerbach Publishers Inc, 1973.
  • Carl Hewitt, et al. Inducción de actores y metaevaluación Archivado el 15/11/2022 en Wayback Machine Actas de la conferencia del Simposio ACM sobre principios de lenguajes de programación, enero de 1974.
  • Carl Hewitt, et al. Semántica conductual de la estructura de control no recursiva Archivado el 10-06-2018 en Wayback Machine Actas del Coloquio sobre la Programación, abril de 1974.
  • Irene Greif y Carl Hewitt. Semántica de actores de PLANNER-73. Archivado el 5 de febrero de 2021 en Wayback Machine. Actas de la conferencia del Simposio de la ACM sobre Principios de Lenguajes de Programación. Enero de 1975.
  • Carl Hewitt. Cómo usar lo que sabes. IJCAI. Septiembre de 1975.
  • Alan Kay y Adele Goldberg. Manual de instrucciones de Smalltalk-72. Memorando Xerox PARC SSL-76-6. Mayo de 1976.
  • Edsger Dijkstra . Una disciplina de programación. Prentice Hall. 1976.
  • Carl Hewitt y Henry Baker, Actores y Funcionales Continuos. Actas de la Conferencia de Trabajo de la IFIP sobre la Descripción Formal de los Conceptos de Programación. 1-5 de agosto de 1977.
  • Carl Hewitt y Russ Atkinson. Sincronización en sistemas de actores. Actas del 4.º simposio ACM SIGACT-SIGPLAN sobre principios de lenguajes de programación. 1977.
  • 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. Una teoría computacional de la animación. Archivado el 18 de agosto de 2017 en Wayback Machine . Tesis doctoral del MIT EECS. 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.
  • Nissim Francez , CAR Hoare, Daniel Lehmann y Willem-Paul de Roever . Semántica del no determinismo, la concurrencia y la comunicación. Revista de Ciencias de la Computación y de Sistemas. Diciembre de 1979.
  • George Milne y Robin Milner . Procesos concurrentes y su sintaxis. JACM. Abril de 1979.
  • Daniel Theriault. Introducción al lenguaje del Acto 1. Memorando 672 del MIT sobre IA. Abril de 1982.
  • Daniel Theriault. Problemas en el diseño e implementación del Acto 2. Archivado el 8 de abril de 2019 en Wayback Machine. Informe técnico 728 del MIT AI. Junio ​​de 1983.
  • Henry Lieberman. Un simulador orientado a objetos para la conferencia sobre apicultura de la Asociación Estadounidense de Inteligencia Artificial, Washington, D.C., agosto de 1983.
  • Carl Hewitt y Peter de Jong. Análisis de los roles de las descripciones y las acciones en los sistemas abiertos. Actas de la Conferencia Nacional sobre Inteligencia Artificial. 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.
  • CAR Hoare . Comunicación de procesos secuenciales. Archivado el 1 de febrero de 2021 en Wayback Machine . Prentice Hall. 1985.
  • Carl Hewitt. El desafío de los sistemas abiertos . Byte. Abril de 1985. Reimpreso en Los fundamentos de la inteligencia artificial: un libro de referencia. Cambridge University Press. 1990.
  • Carl Manning. Traveler: el observatorio de actores ECOOP 1987. También aparece en Lecture Notes in Computer Science , vol. 276.
  • William Athas y Charles Seitz Multicomputadoras: computadoras concurrentes de paso de mensajes Archivado el 5 de febrero de 2021 en Wayback Machine 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. Archivado el 25/11/2020 en Wayback Machine. Rapport de Recherche 88–58, RXF-LITP, París, Francia, septiembre de 1988.
  • William Dally y Wills, D. Mecanismos universales para la concurrencia Archivado el 18-06-2018 en Wayback Machine PARLE 1989.
  • W. Horwat, A. Chien y W. Dally. Experiencia con CST: Programación e implementación. Archivado el 14 de mayo de 2021 en Wayback Machine PLDI. 1989.
  • Carl Hewitt. Hacia una semántica de sistemas de información abiertos. Actas del 10º Taller Internacional sobre Inteligencia Artificial Distribuida. 23-27 de octubre de 1990. Bandera, Texas.
  • Akinori Yonezawa, Ed. ABCL: Un sistema concurrente orientado a objetos. MIT Press. 1990.
  • K. Kahn y Vijay A. Saraswat, " Los actores como un caso especial de programación con restricciones (lógicas) concurrentes ", en SIGPLAN Notices , octubre de 1990. Describe Janus .
  • Carl Hewitt. Semántica de los sistemas de información abiertos . Revista de Inteligencia Artificial. Enero de 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.
  • Carl Hewitt y Gul Agha. Lenguajes con cláusulas de Horn protegidas: ¿son deductivos y lógicos? Conferencia Internacional sobre Sistemas Informáticos de Quinta Generación, Ohmsha, 1988. Tokio. También en Inteligencia Artificial en el MIT , vol. 2. MIT Press, 1991.
  • William Dally, et al. El procesador controlado por mensajes: un nodo de procesamiento multicomputadora con mecanismos eficientes. Archivado el 5 de febrero de 2021 en Wayback Machine IEEE Micro . Abril de 1992.
  • S. Miriyala, G. Agha y Y. Sami. Visualización de programas de actores mediante redes de transición de predicados. Archivado el 10 de noviembre de 2020 en Wayback Machine . Revista de Programación Visual. 1992.
  • Carl Hewitt y Carl Manning. Arquitectura de negociación para la gestión de crisis a gran escala. Taller AAAI-94 sobre modelos de gestión de conflictos en la resolución cooperativa de problemas. Seattle, Washington. 4 de agosto de 1994.
  • Carl Hewitt y Carl Manning. Infraestructuras sintéticas para sistemas multiagencia. Actas de ICMAS '96. Kioto, Japón. 8-13 de diciembre de 1996.
  • S. Frolund. Coordinación de objetos distribuidos: un enfoque basado en actores para la sincronización. MIT Press. Noviembre de 1996.
  • W. Kim. ThAL: Un sistema de actores para computación concurrente eficiente y escalable. Archivado el 31 de agosto de 2017 en Wayback Machine . Tesis doctoral. Universidad de Illinois en Urbana-Champaign. 1997.
  • Jean-Pierre Briot. Acttalk: Un marco para la programación concurrente orientada a objetos: diseño y experiencia. Segundo taller Francia-Japón. 1999.
  • N. Jamali, P. Thati y G. Agha. Una arquitectura basada en actores para personalizar y controlar conjuntos de agentes. Archivado el 25/11/2020 en Wayback Machine IEEE Intelligent Systems. 14(2). 1999.
  • 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.
  • M. Astley, D. Sturman y G. Agha. Middleware personalizable para software distribuido modular. Archivado el 31 de agosto de 2017 en Wayback Machine CACM. 44(5) 2001.
  • Edward Lee, S. Neuendorffer y M. Wirthlin. Diseño orientado a actores de sistemas de hardware y software embebidos. Archivado el 20 de octubre de 2016 en Wayback Machine. Revista de Circuitos, Sistemas y Computadoras . 2002.
  • P. Thati, R. Ziaei y G. Agha. Una teoría de pruebas de mayo para actores. Métodos formales para sistemas distribuidos abiertos basados ​​en objetos. Marzo de 2002.
  • P. Thati, R. Ziaei y G. Agha. Una teoría de pruebas de mayo para cálculos asíncronos con localidad y sin coincidencia de nombres. Metodología algebraica y tecnología de software. Springer Verlag. Septiembre de 2002. LNCS 2422.
  • Stephen Neuendorffer. Metaprogramación orientada a actores. Archivado el 25 de septiembre de 2020 en Wayback Machine . Tesis doctoral. Universidad de California, Berkeley. Diciembre de 2004.
  • Carl Hewitt (2006a) El repetido declive de la programación lógica y por qué resurgirá. Qué 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.
  • Carl Hewitt (2006b) ¿Qué es el compromiso? Físico, organizacional y social. Archivado el 11 de febrero de 2021 en Wayback Machine COIN@AAMAS. 27 de abril de 2006b.
  • Carl Hewitt (2007a) ¿Qué es el compromiso? Aspectos físicos, organizacionales y sociales (Revisado) Pablo Noriega et al., editores. LNAI 4386. Springer-Verlag. 2007.
  • Carl Hewitt (2007b) La computación organizacional a gran escala requiere paraconsistencia y reflexión no estratificadas. Archivado el 25/11/2020 en Wayback Machine COIN@AAMAS'07.
  • D. Charousset, TC Schmidt, R. Hiesgen y M. Wählisch. Actores nativos: una plataforma de software escalable para entornos distribuidos y heterogéneos en AGERE! '13 Actas del taller de 2013 sobre programación basada en actores, agentes y control descentralizado.
  • Hewitt, Meijer y Szyperski: El modelo actoral (todo lo que siempre quisiste saber, pero tenías miedo de preguntar). Canal 9 de Microsoft. 9 de abril de 2012. Vídeo en YouTube.
  • Java funcional archivado el 9 de julio de 2011 en Wayback Machine : una biblioteca de Java que incluye una implementación de actores concurrentes con ejemplos de código en Java estándar y estilo BGGA de Java 7.
  • ActorFoundry es una biblioteca basada en Java para la programación de actores. Su sintaxis Java familiar, un archivo de compilación Ant y numerosos ejemplos hacen que su uso sea sencillo.
  • ActiveJava : una extensión prototipo del lenguaje Java para la programación basada en actores.
  • Akka : una biblioteca basada en actores para Scala y Java, de Lightbend Inc.
  • GPars : una biblioteca de concurrencia para Apache Groovy y Java.
  • Biblioteca de agentes asíncronos : biblioteca de actores de Microsoft para Visual C++. "La biblioteca de agentes es una biblioteca de plantillas de C++ que promueve un modelo de programación basado en actores y el paso de mensajes dentro del proceso para tareas de flujo de datos y canalización de grano grueso."
  • ActorThread en C++11 : plantilla base que proporciona la esencia del modelo de actor sobre hilos desnudos en C++11 estándar.