modelo de actor

Modelo de computación concurrente

El modelo de actor en informática es un modelo matemático de computación concurrente que trata a un actor como el componente básico de la computación concurrente. En respuesta a un mensaje que recibe, 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 a través de mensajes (eliminando la necesidad de sincronización basada en bloqueos ).

El modelo de actor se originó en 1973. ^[1] Se ha utilizado como marco para una comprensión teórica de la computación y 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 actor y cálculos de proceso .

Historia

Según Carl Hewitt , a diferencia de los modelos de computación anteriores, el modelo del actor se inspiró en la física , incluidas la relatividad general y la mecánica cuántica . ^{[ cita requerida ]} También fue influenciado por los lenguajes de programación Lisp , Simula , las primeras versiones de Smalltalk , sistemas basados ​​en capacidades y conmutación de paquetes . Su desarrollo estuvo "motivado por la perspectiva de máquinas informáticas altamente paralelas que constan de docenas, cientos o incluso miles de microprocesadores independientes, cada uno con su propia memoria local y procesador de comunicaciones, comunicándose 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 informáticas multinúcleo y de muchos núcleos 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 operativa para el modelo de actor como parte de su investigación doctoral. ^[3] Dos años más tarde, Henry Baker y Hewitt publicaron un conjunto de leyes axiomáticas para los sistemas de actores. ^{[4] [5]} Otros hitos importantes incluyen la disertación de William Clinger de 1981 que introduce 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 resultó en el pleno desarrollo de la teoría del modelo de actor .

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 realizaron el principal trabajo de implementación de software en el Message Passing Semantics Group de Instituto de Tecnología de Massachusetts (MIT). Los grupos de investigación dirigidos por Chuck Seitz del Instituto de Tecnología de California (Caltech) y Bill Dally del MIT construyeron arquitecturas informáticas que desarrollaron aún más el mensaje que se transmite en el modelo. Consulte Implementación del modelo de actor .

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

Conceptos fundamentales

El modelo actor adopta la filosofía de que todo es actor . Esto es similar a la filosofía de 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 recibe.

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

Desacoplar al remitente de las comunicaciones enviadas fue un avance fundamental del modelo de actor que permitió la comunicación asincrónica y las estructuras de control como patrones de paso de mensajes . ^[8]

Los destinatarios de los mensajes se identifican por su dirección, a veces denominada "dirección postal". Por tanto, un actor sólo puede comunicarse con actores cuyas direcciones tenga. Puede obtenerlos de un mensaje que recibe, o si la dirección es para un actor que él mismo ha creado.

El modelo de actor se caracteriza por la concurrencia inherente de cálculo dentro y entre los actores, la creación dinámica de actores, la inclusión de direcciones de actores en los mensajes y la interacción solo a través del paso directo de mensajes asincrónicos sin 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 actor. Éstas incluyen:

• Semántica operativa ^{[3] [9]}
• Leyes para sistemas de actores ^[4]
• Semántica denotacional ^{[2] [10]}
• Semántica de transición ^[6]

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

• Varias álgebras de actores diferentes ^{[11] [12] [13]}
• Lógica lineal ^[14]

Aplicaciones

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

• El correo electrónico ( correo electrónico ) se puede modelar como un sistema actor. Las cuentas se modelan como actores y las direcciones de correo electrónico como direcciones de actores.
• Los servicios web se pueden modelar como actores con puntos finales del Protocolo simple de acceso a objetos ( SOAP ) modelados como direcciones de actores.
• Los objetos con bloqueos ( por ejemplo , como en Java y C# ) se pueden modelar como un serializador , siempre que sus implementaciones sean tales que los mensajes puedan llegar continuamente (tal vez almacenándose 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 que cada mensaje enviado a un serializador llegará. ^[dieciséis]
• La notación de pruebas y control de pruebas ( TTCN ), tanto TTCN-2 como TTCN-3 , sigue bastante de cerca el modelo de actor. En TTCN, el actor es un componente de prueba: ya sea un componente de prueba paralelo (PTC) o un componente de prueba principal (MTC). Los componentes de prueba pueden enviar y recibir mensajes hacia y desde socios remotos (componentes de prueba pares o interfaz del sistema de prueba), este último identificado 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 los componentes de prueba principales. Las construcciones de lenguaje integradas permiten definir las acciones que se deben tomar 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 ilimitada del no determinismo

Podría decirse que los primeros programas concurrentes fueron manejadores de interrupciones . Durante su funcionamiento normal un ordenador necesitaba poder recibir información del exterior (caracteres de un teclado, paquetes de una red, etc. ). Entonces, cuando llegó la información, se interrumpió la ejecución de la computadora y se llamó a un código especial (llamado controlador de interrupciones) para colocar la información en un búfer de datos donde podría recuperarse posteriormente.

A principios de la década de 1960, se empezaron a utilizar interrupciones para simular la ejecución simultánea de varios programas en un procesador. ^[17] Tener concurrencia con memoria compartida dio lugar al problema del control de concurrencia . Originalmente, este problema se concibió como un problema 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 exclusión mutua. Sin embargo, ninguna de estas soluciones proporcionó una construcción de lenguaje de programación que encapsulara el acceso a recursos compartidos. Esta encapsulación se logró posteriormente mediante la construcción del serializador ([Hewitt y Atkinson 1977, 1979] y [Atkinson 1980]).

Los primeros modelos de computación ( por ejemplo , las máquinas de Turing , las postproducciones, el cálculo lambda , etc. ) se basaban en las matemáticas y hacían uso de un estado global para representar un paso computacional (posteriormente generalizado en [McCarthy y Hayes 1969] y [Dijkstra). 1976] ver Ordenamiento de eventos versus estado global ). Cada paso computacional fue de un estado global del cálculo al siguiente estado global. El enfoque del estado global continuó en la teoría de los autómatas para máquinas de estados finitos y máquinas de pila de empuje , incluidas sus versiones no deterministas . Estos autómatas no deterministas tienen la propiedad de no determinismo acotado ; es decir, si una máquina siempre se detiene cuando se arranca 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 del 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 la atención de una solicitud puede volverse ilimitada como resultado del arbitraje de la contienda por recursos compartidos y al mismo tiempo garantizar que la solicitud eventualmente será reparado . 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 comenzara en un estado bien definido podría terminar sólo en un número limitado de estados [Dijkstra 1976]. En consecuencia, su modelo no podía ofrecer la garantía de servicio. Dijkstra argumentó que era imposible implementar un no determinismo ilimitado.

Hewitt argumentó lo contrario: no se puede imponer ningún límite al tiempo que tarda un circuito computacional llamado árbitro en establecerse (ver metaestabilidad (electrónica) ). ^[21] Los árbitros se utilizan en las computadoras para hacer frente a la circunstancia de que los relojes de las computadoras funcionan de forma asincrónica con respecto a la entrada desde el exterior, por ejemplo , entrada del teclado, acceso al disco, entrada de la red, etc. Por lo tanto, podría tomar un tiempo ilimitado para que un mensaje se envíe a una computadora para ser recibida y mientras tanto la computadora podría atravesar un número ilimitado de estados.

El modelo de actor presenta un no determinismo ilimitado que Will Clinger capturó en un modelo matemático utilizando la teoría de dominios . ^[2] En el modelo de actor, no existe un estado global. ^{[ dudoso – discutir ]}

Comunicación directa y asincronía.

Los mensajes en el modelo de actor no necesariamente se almacenan en buffer. Esta fue una ruptura radical con enfoques anteriores de modelos de computación concurrente. La falta de buffering causó muchos malentendidos en el momento del desarrollo del modelo de actor y sigue siendo un tema controvertido. Algunos investigadores argumentaron que los mensajes se almacenan en el "éter" o "entorno". Además, los mensajes en el modelo de actor simplemente se envían (como paquetes en IP ); no es necesario un apretón de manos sincrónico con el destinatario.

La creación de actores más direcciones en mensajes significa topología variable

Un desarrollo natural del modelo de actor fue permitir 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 ningún campo obligatorio: podrían estar vacías. Por supuesto, si el remitente de una comunicación desea que un destinatario tenga acceso a direcciones que el destinatario aún no tiene, la dirección tendría que enviarse en la comunicación.

Por ejemplo, un actor podría necesitar enviar un mensaje a un actor destinatario del que luego espera recibir una respuesta, pero la respuesta en realidad será manejada por un tercer componente de actor que ha sido configurado para recibir y manejar la respuesta (por ejemplo , un actor diferente que implementa el patrón de 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 manejará la respuesta. Este tercer actor que manejará la respuesta se llama reanudación (a veces también llamado continuación o marco de pila ). Cuando el actor destinatario está listo para enviar una respuesta, envía el mensaje de respuesta a la dirección del actor de reanudación que se incluyó en la comunicación original.

Entonces, la capacidad de los actores para crear nuevos actores con los que pueden intercambiar comunicaciones, junto con la capacidad de incluir las direcciones de otros actores en los mensajes, les da a los actores la capacidad de crear y participar en relaciones topológicas arbitrariamente variables entre sí, de manera muy parecida a como lo hacen los actores. Los objetos en Simula y otros lenguajes orientados a objetos también pueden componerse relacionalmente en topologías variables de objetos de intercambio de mensajes.

inherentemente concurrente

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 que derivaba del cálculo concurrente como se explica en la teoría del modelo de actor .

No hay requisitos en el orden de llegada del mensaje.

Hewitt se opuso a agregar el requisito de que los mensajes deben llegar en el orden en que se envían al actor. Si se desea ordenar los mensajes de salida, se puede modelar mediante un actor de cola que proporcione esta funcionalidad. Un actor de cola de este tipo pondría en cola los mensajes que llegaran para poder recuperarlos en orden FIFO . Entonces, si un actor Xenvió un mensaje M1a un actor Yy luego le Xenvió otro mensaje , no hay ningún requisito que llegue antes .M2YM1YM2

En este sentido, el modelo de actor refleja los sistemas de conmutación de paquetes que no garantizan que los paquetes deban recibirse en el orden de envío. No proporcionar la garantía de orden de entrega permite cambiar paquetes a paquetes en búfer, utilizar múltiples rutas para enviar paquetes, reenviar paquetes dañados y proporcionar otras optimizaciones.

Por ejemplo, a los actores se les permite canalizar el procesamiento de mensajes. Lo que esto significa es que en el curso del procesamiento de un mensaje M1, un actor puede designar el comportamiento que se utilizará para procesar el siguiente mensaje y luego, de hecho, comenzar a procesar otro mensaje M2antes de que haya terminado de procesarse M1. El hecho de que a un actor se le permita canalizar el procesamiento de mensajes no significa que deba canalizar el procesamiento. La canalización de un mensaje es una cuestión de ingeniería. ¿Cómo sabría un observador externo si el procesamiento de un mensaje por parte de un actor ha sido canalizado? No hay ambigüedad en la definición de actor creada por la posibilidad de canalización. Por supuesto, es posible realizar la optimización de la canalización de forma incorrecta en algunas implementaciones, en cuyo caso puede producirse un comportamiento inesperado.

Localidad

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

Localidad significa que al procesar un mensaje, un actor puede enviar mensajes solo a las direcciones que recibe en el mensaje, direcciones que ya tenía antes de recibir el mensaje y direcciones para actores que crea mientras procesa el mensaje. (Pero vea Sintetizar direcciones de actores).

Además, localidad significa que no hay cambios simultáneos en múltiples ubicaciones. En este sentido se diferencia de otros modelos de concurrencia, por ejemplo , el modelo de red de Petri en el que los tokens se retiran simultáneamente de múltiples ubicaciones y se colocan en otras ubicaciones.

Componer sistemas de actores.

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

Comportamientos

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

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

Modelado de otros sistemas de concurrencia

Otros sistemas de concurrencia ( por ejemplo , cálculos de procesos ) se pueden modelar 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 cerrados en el sentido de que no reciben comunicaciones del exterior. La denotación matemática denotada por un sistema cerrado se construye a partir de un comportamiento inicial y una función de aproximación del comportamiento. Estos obtienen aproximaciones cada vez mejores y construyen una denotación (significado) de la siguiente manera [Hewitt 2008; Clinger 1981]: ${\displaystyle {\mathtt {S}}}$ ${\displaystyle \bot _{\mathtt {S}}}$ ${\displaystyle \mathbf {progression} _{\mathtt {S}}.}$ ${\displaystyle {\mathtt {S}}}$

${\displaystyle \mathbf {Denote} _{\mathtt {S}}\equiv \lim _{i\to \infty }\mathbf {progression} _{{\mathtt {S}}^{i}}(\bot _{\mathtt {S}})}$

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

Una consecuencia del teorema anterior es que un actor finito puede responder de manera no determinista con un número incontable ^{[ aclarar ]} de resultados diferentes.

Relación con la programación lógica

Una de las motivaciones clave para el desarrollo del modelo de actor fue comprender y abordar los problemas de la estructura de control que surgieron en el desarrollo del lenguaje de programación Planner . ^{[ cita necesaria ]} Una vez que se definió inicialmente el modelo de actor, un desafío importante fue comprender el poder del modelo en relación con la tesis de Robert Kowalski de que "la computación puede subsumirse en la deducción". Hewitt argumentó que la tesis de Kowalski resultó ser falsa para el cálculo concurrente en el modelo de actor (ver Indeterminación en el cálculo concurrente ).

Sin embargo, se intentó extender la programación lógica al cálculo 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 siguen deductivamente de los pasos anteriores (ver Indeterminación en la computación concurrente ). Recientemente, la programación lógica se ha integrado en el modelo de actor de una manera que mantiene la semántica lógica. ^[21]

Migración

La migración en el modelo de actor es la capacidad de los actores de cambiar de ubicación. Por ejemplo , en su disertación, Aki Yonezawa modeló una oficina de correos en la que los actores clientes podían entrar, cambiar de ubicación mientras operaban y salir. Un actor que puede migrar se puede modelar teniendo un actor de ubicación que cambie cuando el actor migra. Sin embargo, la fidelidad de este modelo es controvertida y objeto de investigación. ^{[ cita necesaria ]}

Seguridad

La seguridad de los actores se puede proteger de las siguientes maneras:

• cableado en el que los actores están conectados físicamente
• hardware informático como en Burroughs B5000 , máquina Lisp , etc.
• máquinas virtuales como en la máquina virtual Java , Common Language Runtime , etc.
• sistemas operativos como en sistemas basados ​​en capacidades
• firma y/o cifrado de actores y sus direcciones

Sintetizando direcciones de actores.

Un punto delicado en el modelo de actor es la capacidad de sintetizar la dirección de un actor. En algunos casos, se puede utilizar la seguridad para evitar la síntesis de direcciones (consulte Seguridad). Sin embargo, si la dirección de un actor es simplemente una cadena de bits, entonces claramente se puede sintetizar, aunque puede ser difícil o incluso imposible adivinar la dirección de un actor si las cadenas de bits son lo suficientemente largas. SOAP utiliza una URL para la dirección de un punto final donde se puede localizar a un actor. Dado que una URL es una cadena de caracteres, se puede sintetizar claramente, aunque el cifrado puede hacer que sea prácticamente imposible de adivinar.

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

Contraste con otros modelos de concurrencia de 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 se diferenciaba 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 sincrónica. El modelo de procesos secuenciales de comunicación (CSP) original ^[24] publicado por Tony Hoare se diferenciaba 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 la comunicación se basaba en el paso de mensajes sincrónico. sobre los nombres de los procesos (consulte Modelo de actor e historial de 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 de comunicación y el cálculo π .

Estos primeros modelos de Milner y Hoare tenían ambos la propiedad de un no determinismo acotado. La CSP teórica moderna ([Hoare 1985] y [Roscoe 2005]) proporciona explícitamente un no determinismo ilimitado.

Las redes de Petri y sus extensiones (por ejemplo, las redes de Petri de colores) son como actores en el sentido de que se basan en el paso de mensajes asincrónicos y en el no determinismo ilimitado, mientras que son como los primeros CSP en el sentido de que definen topologías fijas de pasos de procesamiento elementales (transiciones) y depósitos de mensajes. (lugares).

Influencia

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

Teoría

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

Ahora bien, el cálculo lambda puro se construye con sólo 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 el mismo tipo de cosas: un actor.

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

Entonces, en el espíritu de Hewitt, nuestro primer paso es exigir que todas las cosas denotadas por términos o a las que se accede mediante nombres (valores, registros, operadores, procesos, objetos) sean todas del mismo tipo de cosas; todos deberían ser procesos.

Práctica

El modelo de actor ha tenido una gran influencia en la práctica comercial. Por ejemplo, Twitter ha utilizado actores para lograr escalabilidad. ^[26] Además, Microsoft ha utilizado el modelo de actor en el desarrollo de su biblioteca de agentes asincrónicos. ^[27] Hay muchas otras bibliotecas de actores enumeradas en la sección de marcos y bibliotecas de actores 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, incluidos los siguientes:

• Escalabilidad : el desafío de ampliar la concurrencia tanto a nivel local como no local.
• Transparencia : cerrar el abismo entre la concurrencia local y no local. La transparencia es actualmente un tema controvertido. Algunos investigadores ^{[ ¿quién? ]} han abogado por una separación estricta entre la concurrencia local que utiliza lenguajes de programación concurrentes (por ejemplo, Java y C# ) de la concurrencia no local que utiliza SOAP para servicios web . La separación estricta produce una falta de transparencia que causa problemas cuando es deseable/necesario cambiar entre el acceso local y no local a los servicios web (ver Computación distribuida ).
• Inconsistencia : la inconsistencia es la norma porque todos los sistemas de conocimiento muy grandes sobre las interacciones del sistema de información humano son inconsistentes. Esta inconsistencia se extiende a la documentación y especificaciones de sistemas muy grandes (por ejemplo, software de Microsoft Windows, etc.), que son internamente inconsistentes.

Muchas de las ideas introducidas en el modelo de actor ahora también encuentran aplicación en sistemas multiagente por las mismas razones [Hewitt 2006b 2007b]. La diferencia clave es que los sistemas de agentes (en la mayoría de las definiciones) imponen restricciones adicionales a los actores, exigiéndoles por lo general que hagan uso de compromisos y objetivos.

Programación con actores.

Varios lenguajes de programación diferentes emplean el modelo de actor o alguna variación del mismo. Estos idiomas incluyen:

Lenguajes de programación de actores tempranos

• Acto 1, 2 y 3 ^{[28] [29]}
• actuar hablar ^[30]
• aní ^[31]
• Cantante ^[32]
• Rosetón ^[33]

Lenguajes de programación de actores posteriores

• ABCL
• Charla ambiental ^[34]
• Aksum ^[35]
• Idioma del actor CAL
• D
• Dardo
• mi
• Elixir
• erlang
• fantasma
• humus ^[36]
• yo
• LFE
• bis ^[37]
• Poni ^{[38] [39]}
• Proyecto Ptolomeo
• P ^[40]
• P# ^[41]
• Lenguaje de modelado Rebeca
• Reia
• rubí ^[42]
• SALSA ^[43]
• Escala ^{[44] [45]}
• Swift (lenguaje de programación) ^[46]
• TNSDL

Bibliotecas y marcos de actores.

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

Ver también

• agente autónomo
• Flujo de datos
• Gordon Pask
• Autómata de entrada/salida
• Metáfora de la comunidad científica

Referencias

1. Hewitt, Carl ; Obispo, Pedro; Steiger, Richard (1973). "Un formalismo de actor modular universal para la inteligencia artificial". IJCAI. {{cite journal}}: Citar diario requiere |journal=( ayuda )
2. William Clinger (junio de 1981). "Fundamentos de la semántica del actor". Tesis Doctoral en Matemáticas. MIT. hdl :1721.1/6935. {{cite journal}}: Citar diario requiere |journal=( ayuda )
3. Irene Greif (agosto de 1975). "Semántica de la comunicación de procesos paralelos". Tesis Doctoral EECS. MIT. {{cite journal}}: Citar diario requiere |journal=( ayuda )
4. Henry Baker ; Carl Hewitt (agosto de 1977). "Leyes para la Comunicación de Procesos Paralelos". IFIP. {{cite journal}}: Citar diario requiere |journal=( ayuda )
5. «Leyes para la Comunicación de Procesos Paralelos» (PDF) . 10 de mayo de 1977. Archivado (PDF) desde el original el 24 de junio de 2016 . Consultado el 11 de junio de 2014 .
6. Gul Agha (1986). "Actores: un modelo de computación concurrente en sistemas distribuidos". Tesis doctoral. Prensa del MIT. hdl :1721.1/6952. {{cite journal}}: Citar diario requiere |journal=( ayuda )
7. "Inicio". Osl.cs.uiuc.edu. Archivado desde el original el 22 de febrero de 2013 . Consultado el 2 de diciembre de 2012 .
8. Carl Hewitt. Ver las estructuras de control como patrones de transmisión de mensajes Journal of Artificial Intelligence. Junio ​​de 1977.
9. Gul Agha; Ian Mason; Scott Smith; Carolyn Talcott (enero de 1993). "Una base para la computación de actores". Revista de programación funcional .
10. Carl Hewitt (27 de abril de 2006). "¿Qué es el Compromiso? Físico, Organizacional y Social" (PDF) . Archivado (PDF) desde el original el 11 de febrero de 2021 . Consultado el 26 de mayo de 2006 . {{cite journal}}: Citar diario 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–18. doi :10.1007/978-0-387-35562-7_2. ISBN 978-1-4757-5266-3. Archivado (PDF) desde el original el 26 de julio de 2018 . Consultado el 8 de abril de 2019 .
12. M. Gaspari; G. Zavattaro (1999). "Un álgebra de actores". Métodos formales para sistemas abiertos basados ​​en objetos. {{cite journal}}: Citar diario 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 desde el original (PDF) el 20 de abril de 2004. {{cite journal}}: Citar diario requiere |journal=( ayuda )
14. John Darlington; YK Guo (1994). "Formalizando actores en lógica lineal". Congreso Internacional sobre Sistemas de Información Orientados a Objetos. {{cite journal}}: Citar diario requiere |journal=( ayuda )
15. "¿Qué es el modelo de actor y cuándo debería utilizarlo?". Matt Ferderer . Archivado desde el original el 25 de agosto de 2021 . Consultado el 25 de agosto de 2021 .
16. Cheung, Leo (25 de julio de 2017). "Por qué Akka y el modelo de actor brillan en las aplicaciones de IoT". InfoMundo . Archivado desde el original el 25 de agosto de 2021 . Consultado el 25 de agosto de 2021 .
17. Hansen, por Brinch (2002). Los orígenes de la programación concurrente: de los semáforos a las llamadas a procedimientos remotos . Saltador. ISBN 978-0-387-95401-1.
18. Hansen, por Brinch (1996). "Monitores y Pascal concurrente: una historia personal". Comunicaciones de la ACM : 121–172.
19. Hoare, Tony (octubre de 1974). "Monitores: un concepto de estructuración del sistema operativo". Comunicaciones de la ACM . 17 (10): 549–557. doi : 10.1145/355620.361161 . S2CID  1005769.
20. Hansen, Per Brinch (julio de 1973). Principios del sistema operativo . Prentice Hall.
21. Hewitt, Carl (2012). "¿Qué es la computación? Modelo de actor versus modelo de Turing". En Zenil, Héctor (ed.). Un universo computable: comprensión de la computación y exploración de la naturaleza como computación. Dedicado a la memoria de Alan M. Turing en el centenario de su nacimiento . Compañía editorial científica mundial.
22. Federico Knabe. Un protocolo distribuido para comunicación basada en canales con elección PARLE 1992 Archivado el 31 de agosto de 2017 en Wayback Machine .
23. Robin Milner. Procesos: un modelo matemático de agentes informáticos en el coloquio de lógica 1973.
24. COCHE Ronco. Comunicación de procesos secuenciales CACM. Agosto de 1978.
25. Milner, Robin (1993). "Elementos de interacción". Comunicaciones de la ACM . 36 : 78–89. doi : 10.1145/151233.151240 .
26. "Cómo está escalando Twitter« Blog de Waiming Mok ". Waimingmok.wordpress.com. 2009-06-27. Archivado desde el 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 asincrónicos Archivado el 31 de agosto de 2017 en Wayback Machine " MSDN Septiembre de 2010.
28. Henry Lieberman (junio de 1981). "Una vista previa del acto 1". Nota MIT AI 625. hdl : 1721.1/6350. {{cite journal}}: Citar diario requiere |journal=( ayuda )
29. Henry Lieberman (junio de 1981). "Pensar en muchas cosas a la vez sin confundirse: paralelismo en el acto 1". Nota MIT AI 626. hdl : 1721.1/6351. {{cite journal}}: Citar diario requiere |journal=( ayuda )
30. Jean-Pierre Briot. Acttalk: Un marco para la experiencia y el diseño de programación concurrente orientada a objetos 2º 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 la tesis doctoral Wayback Machine MIT EECS. Agosto de 1979.
32. William Athas y Nanette Boden Cantor: un sistema de programación de actores para informática científica Archivado el 8 de abril de 2019 en Wayback Machine en las actas del taller de NSF sobre programación concurrente basada en objetos. 1988. Número especial de Avisos SIGPLAN.
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 paralelo". Eweek.com. Archivado desde el original el 29 de julio de 2012 . Consultado el 2 de diciembre de 2012 .
36. "Humus". Dalnefre.com. Archivado desde el 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: un vistazo al bis del lenguaje paralelo". Métodos formales para programación multinúcleo . Publicaciones internacionales Springer: 1–56.
38. "El lenguaje del pony". Archivado desde el original el 4 de septiembre de 2018 . Consultado el 21 de marzo de 2016 .
39. Clebsch, Sylvan; Drossopoulou, Sofía; Bendición, Sebastián; McNeil, Andy (2015). "Negar capacidades a actores rápidos y seguros". Actas del V Taller Internacional sobre Programación Basada en Actores, Agentes y Control Descentralizado - AGERE! 2015 . págs. 1–12. doi :10.1145/2824815.2824816. ISBN 9781450339018. S2CID  415745.por Sylvan Clebsch, Sophia Drossopoulou, Sebastian Blessing, Andy McNeil
40. "El lenguaje P". GitHub . 2019-03-08. Archivado desde el original el 15 de enero de 2021 . Consultado el 1 de febrero de 2017 .
41. "El lenguaje P#". GitHub . 2019-03-12. Archivado desde el original el 23 de marzo de 2021 . Consultado el 1 de febrero de 2017 .
42. "clase Ractor". Ruby-lang.org. Archivado desde el original el 2022-03-02 . Consultado el 2 de marzo de 2022 .
43. Carlos Varela y Gul Agha (2001). "Programación de Sistemas Abiertos Reconfigurables Dinámicamente con SALSA". Avisos ACM SIGPLAN. "Actas de seguimiento de tecnología intrigante de OOPSLA'2001" . 36 .
44. Philipp Haller y Martin Odersky (septiembre de 2006). "Programación basada en eventos sin inversión de control" (PDF) . Proc. JMLC 2006. Archivado (PDF) desde el original el 9 de noviembre de 2020 . Consultado el 5 de abril de 2007 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
45. Philipp Haller y Martin Odersky (enero de 2007). «Actores que Unifican Hilos y Acontecimientos» (PDF) . Informe técnico LAMP 2007. Archivado desde el original (PDF) el 7 de junio de 2011 . Consultado el 10 de diciembre de 2007 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
46. "Guía de lenguaje Swift: simultaneidad". Archivado desde el original el 1 de marzo de 2022 . Consultado el 11 de marzo de 2022 .
47. "actor - 0.9.1 · David Bonet · Crates.io". cajas.io. Archivado desde el original el 5 de febrero de 2021 . Consultado el 16 de abril de 2020 .
48. Bulut, Mahmut (15 de diciembre de 2019). "Bastión en Crates.io". Cajas.io . Archivado desde el original el 5 de febrero de 2021 . Consultado el 15 de diciembre de 2019 .
49. "actix - 0.10.0 · Rob Ede · Crates.io". cajas.io. Archivado desde el original el 14 de mayo de 2021 . Consultado el 28 de febrero de 2021 .
50. "Lanzamientos · zakgof/actr · GitHub". Github.com. Archivado desde el original el 26 de octubre de 2020 . Consultado el 16 de abril de 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 Akka | @lightbend". Archivado desde el original el 22 de septiembre de 2022 . Consultado el 24 de septiembre de 2022 .
53. Akka.NET v1.4.10 Versión estable GitHub - akkadotnet/akka.net: Puerto de actores de Akka para .NET., Akka.NET, 2020-10-01, archivado desde el original el 2021-02-24 , recuperado en 2020- 10-01
54. Apache Pekko (Graduado), Apache Software Foundation
55. Srinivasan, Sriram; Alan Mycroft (2008). "Kilim: actores de tipo aislado para Java" (PDF) . Conferencia Europea sobre Programación Orientada a Objetos ECOOP 2008 . Chipre. Archivado (PDF) desde el original el 28 de octubre de 2020 . Consultado el 25 de febrero de 2016 .
56. "Lanzamientos · kilim / kilim · GitHub". Github.com. Archivado desde el original el 16 de octubre de 2020 . Consultado el 3 de junio de 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". Hackeo . Consultado el 1 de mayo de 2024 .
59. "CloudI: Una nube al nivel más bajo · Actividad". fuenteforge.net . Consultado el 3 de enero de 2024 .
60. "Etiquetas · GNOME/desorden · GitLab". gitlab.gnome.org. Archivado desde el original el 3 de junio de 2019 . Consultado el 3 de junio de 2019 .
61. "Lanzamientos · ncthbrt/nact · GitHub". GitHub . Archivado desde el original el 27 de noviembre de 2020 . Consultado el 3 de junio de 2019 .
62. "Cambios - retlang - Simultaneidad basada en mensajes en .NET - Google Project Hosting". Archivado desde el original el 24 de noviembre de 2015 . Consultado el 25 de febrero de 2016 .
63. "jetlang-0.2.9-bin.zip - jetlang - jetlang-0.2.9-bin.zip - Simultaneidad basada en mensajes para Java - Alojamiento de proyectos de Google". 2012-02-14. Archivado desde el original el 14 de enero de 2016 . Consultado el 25 de febrero de 2016 .
64. "Lanzamientos de GPars". GitHub. Archivado desde el original el 4 de septiembre de 2020 . Consultado el 25 de febrero de 2016 .
65. "Lanzamientos · oosmos/oosmos · GitHub". GitHub. Archivado desde el original el 13 de noviembre de 2020 . Consultado el 3 de junio de 2019 .
66. "Pulsar Diseño y Actores". Archivado desde el original el 4 de julio de 2015.
67. "Documentación de Pulsar". Archivado desde el original el 26 de julio de 2013.
68. "Cambios: documentación de Pykka 2.0.0". pykka.org. Archivado desde el original el 5 de febrero de 2021 . Consultado el 3 de junio de 2019 .
69. "Theron-Ashton Mason". Archivado desde el original el 31 de marzo de 2019 . Consultado el 29 de agosto de 2018 .
70. "Theron - Versión 6.00.02 lanzada". Theron-library.com. Archivado desde el original el 16 de marzo de 2016 . Consultado el 25 de febrero de 2016 .
71. "Terón". Theron-library.com. Archivado desde el original el 4 de marzo de 2016 . Consultado el 25 de febrero de 2016 .
72. "Lanzamientos · puniverse/quasar · GitHub". GitHub . Archivado desde el original el 15 de diciembre de 2020 . Consultado el 3 de junio de 2019 .
73. "Cambios - actor-cpp - Una implementación del modelo de actor para C++ - Google Project Hosting". Archivado desde el original el 18 de noviembre de 2015 . Consultado el 2 de diciembre de 2012 .
74. "Historial de confirmaciones · s4/s4 · Apache". apache.org. Archivado desde el original el 6 de marzo de 2016 . Consultado el 16 de enero de 2016 .
75. "Lanzamientos · actor-framework / actor-framework · GitHub". Github.com. Archivado desde el original el 26 de marzo de 2021 . Consultado el 7 de marzo de 2020 .
76. "celuloide | RubyGems.org | el anfitrión de gemas de tu comunidad". RubyGems.org. Archivado desde el original el 29 de septiembre de 2020 . Consultado el 3 de junio de 2019 .
77. "Comunidad: Actor Framework, revisión LV 2011 (versión 3.0.7)". Decibel.ni.com. 23 de septiembre de 2011. Archivado desde el original el 13 de octubre de 2016 . Consultado el 25 de febrero de 2016 .
78. "Lanzamientos · órbita/órbita · GitHub". GitHub . Consultado el 3 de junio de 2019 .
79. "Herramientas y marcos integrados en tiempo real de QP: examinar archivos en". Fuenteforge.net. Archivado desde el original el 24 de febrero de 2021 . Consultado el 3 de junio de 2019 .
80. "Lanzamientos · Stiffstream/sobjectizer · GitHub". GitHub. Archivado desde el original el 19 de octubre de 2020 . Consultado el 11 de mayo de 2022 .
81. "Lanzamientos · basiliscos / cpp-rotor · GitHub". GitHub. Archivado desde el original el 15 de septiembre de 2020 . Consultado el 17 de mayo de 2022 .
82. "Lanzamientos · dotnet/orleans · GitHub". GitHub. Archivado desde el original el 4 de diciembre de 2020 . Consultado el 21 de septiembre de 2022 .
83. "Lanzamientos funcionales de Java". GitHub. Archivado desde el original el 15 de enero de 2021 . Consultado el 23 de agosto de 2018 .

Otras lecturas

• Gul Agha. Actores: un modelo de computación concurrente en sistemas distribuidos Archivado el 12 de noviembre de 2020 en Wayback Machine . Prensa del MIT 1985.
• Pablo Barán. Sobre redes de comunicaciones distribuidas Transacciones IEEE sobre sistemas de comunicaciones . 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. Incorporación procesal de conocimientos 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 y otros. Inducción de actores y metaevaluación Archivado el 15 de noviembre de 2022 en el Registro de la conferencia Wayback Machine 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 de junio de 2018 en las Actas de Wayback Machine de Colloque sur la Programmation, abril de 1974.
• Irene Greif y Carl Hewitt. Semántica del actor de PLANNER-73 Archivado el 5 de febrero de 2021 en el Registro de la conferencia Wayback Machine del Simposio ACM sobre principios de lenguajes de programación. Enero de 1975.
• Carl Hewitt. Cómo utilizar lo que sabes IJCAI. Septiembre de 1975.
• Alan Kay y Adele Goldberg. Manual de instrucciones Smalltalk-72 Xerox PARC Memo 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 Acta de la conferencia de trabajo IFIP sobre descripción formal de conceptos de programación. 1 al 5 de agosto de 1977.
• Carl Hewitt y Russ Atkinson. Sincronización en sistemas actores Actas del 4to 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 IEEE Journal on Software Engineering. Enero de 1979.
• Ken Kahn. Una teoría computacional de la animación Archivado el 18 de agosto de 2017 en la tesis doctoral Wayback Machine MIT EECS. Agosto de 1979.
• Carl Hewitt, Beppe Attardi y Henry Lieberman. Delegación en las actas de transmisión de mensajes de la Primera Conferencia Internacional sobre Sistemas Distribuidos Huntsville, AL. Octubre de 1979.
• Nissim Francez , CAR Hoare, Daniel Lehmann y Willem-Paul de Roever. Semántica del no determinismo, concurrencia y comunicación Revista de Ciencias de la Computación y Sistemas. Diciembre de 1979.
• George Milne y Robin Milner . Procesos concurrentes y su sintaxis JACM. Abril de 1979.
• Daniel Thériault. Introducción al lenguaje Act-1 Memo 672 del MIT AI. Abril de 1982.
• Daniel Thériault. Problemas en el diseño y la implementación de la Ley 2 Archivado el 8 de abril de 2019 en el informe técnico 728 de Wayback Machine MIT AI. Junio ​​de 1983.
• Henry Liberman. Un simulador orientado a objetos para la Conferencia de Apiarios de la Asociación Estadounidense de Inteligencia Artificial, Washington, DC, agosto de 1983
• Carl Hewitt y Peter de Jong. Análisis de los roles de las descripciones y acciones en sistemas abiertos Actas de la Conferencia Nacional sobre Inteligencia Artificial. Agosto de 1983.
• Carl Hewitt y Henry Lieberman. Problemas de diseño en arquitectura paralela para inteligencia artificial Memo 750 del MIT AI. Noviembre de 1983.
• COCHE 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 La base de la inteligencia artificial: un libro de consulta Cambridge University Press. 1990.
• Carl Manning. Viajero: el observatorio de actores ECOOP 1987. Aparece también 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 informática científica en las actas del taller de NSF sobre programación concurrente basada en objetos. 1988. Número especial de Avisos SIGPLAN.
• Jean-Pierre Briot. De objetos a actores: estudio de una simbiosis limitada en Smalltalk-80 Archivado el 25 de noviembre de 2020 en Wayback Machine Rapport de Recherche 88–58, RXF-LITP, París, Francia, septiembre de 1988
• William Dally y Wills, D. Mecanismos universales de concurrencia Archivado el 18 de junio de 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 la semántica de sistemas de información abiertos Actas del décimo taller internacional sobre inteligencia artificial distribuida. 23 al 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 (lógica) de restricciones concurrentes", en SIGPLAN Notices , octubre de 1990. Describe a Janus .
• Carl Hewitt. Revista Semántica de Sistemas de Información Abierta de Inteligencia Artificial. Enero de 1991.
• Carl Hewitt y Jeff Inman. DAI entre y entre ellos: de "agentes inteligentes" a la ciencia de sistemas abiertos Transacciones IEEE sobre sistemas, el hombre y la cibernética. noviembre/diciembre 1991.
• Carl Hewitt y Gul Agha. Lenguajes de cláusulas de Cuerno Guardado: ¿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. Prensa del MIT 1991.
• William Dally, et al. El procesador basado en mensajes: un nodo de procesamiento multicomputador 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 utilizando redes de transición de predicados Archivado el 10 de noviembre de 2020 en el Wayback Machine Journal of Visual Programming. 1992.
• Carl Hewitt y Carl Manning. Arquitectura de negociación para la gestión de crisis a gran escala AAAI-94 Taller sobre modelos de gestión de conflictos en la resolución cooperativa de problemas. Seattle, WA. 4 de agosto de 1994.
• Carl Hewitt y Carl Manning. Infraestructuras sintéticas para sistemas multiagencia Actas de ICMAS '96. Kyoto, Japón. 8 al 13 de diciembre de 1996.
• S. Frölund. Coordinación de objetos distribuidos: un enfoque basado en actores para la sincronización MIT Press. Noviembre de 1996.
• W. Kim. ThAL: un sistema actor para computación concurrente eficiente y escalable Archivado el 31 de agosto de 2017 en la tesis doctoral de Wayback Machine . Universidad de Illinois en Urbana-Champaign. 1997.
• Jean-Pierre Briot. Acttalk: Un marco para la experiencia y el diseño de programación concurrente orientada a objetos 2º 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 de noviembre de 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. Protocolo simple de acceso a objetos (SOAP) 1.1 W3C Nota. 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 al actor de sistemas integrados de hardware y software Archivado el 20 de octubre de 2016 en Wayback Machine Journal of Circuits, Systems, and Computers . 2002.
• P. Thati, R. Ziaei y G. Agha. Una teoría de pruebas de mayo para métodos formales de actores para sistemas distribuidos abiertos basados ​​​​en objetos. Marzo de 2002.
• P. Thati, R. Ziaei y G. Agha. Una teoría de las pruebas de cálculos asincrónicos con localidad y sin nombre que coincida con la metodología algebraica y la 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 la tesis doctoral de Wayback Machine . Universidad de California, Berkeley. diciembre de 2004
• Carl Hewitt (2006a) La repetida desaparición de la programación lógica y por qué se reencarnará. Qué salió mal y por qué: lecciones de la investigación y las aplicaciones de la IA. Informe Técnico SS-06-08. Prensa AAAI. 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? Físico, Organizacional y Social (Revisado) Pablo Noriega .et al. editores. LNAI 4386. Springer-Verlag. 2007.
• Carl Hewitt (2007b) La informática organizacional a gran escala requiere reflexión y paraconsistencia no estratificada Archivado el 25 de noviembre de 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 2013 sobre Programación basada en actores, agentes y control descentralizado.

enlaces externos

• Hewitt, Meijer y Szyperski: The Actor Model (todo lo que querías saber, pero tenías miedo de preguntar) Microsoft Channel 9. 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 estilo Java estándar y Java 7 BGGA.
• ActorFoundry: una biblioteca basada en Java para programación de actores. La familiar sintaxis de Java, un archivo de compilación ant y un montón de ejemplos hacen que la barrera de entrada sea muy baja.
• ActiveJava: un prototipo de extensión del lenguaje Java para programación de actores.
• Akka: biblioteca basada en actores en Scala y Java, de Lightbend Inc.
• GPars: una biblioteca de concurrencia para Apache Groovy y Java
• Biblioteca de agentes asincrónicos: 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 en proceso para tareas de canalización y flujo de datos de grano grueso".
• ActorThread en C++11: plantilla base que proporciona la esencia del modelo de actor sobre subprocesos desnudos en C++11 estándar