stringtranslate.com

Modelo de actor

El modelo de actor en informática es un modelo matemático de computación concurrente que trata a un actor como el bloque de construcción 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 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 , incluida la relatividad general y la mecánica cuántica . [ cita requerida ] También estuvo influenciado por los lenguajes de programación Lisp , Simula , las primeras versiones de Smalltalk , los sistemas basados ​​en capacidades y la conmutación de paquetes . Su desarrollo estuvo "motivado por la perspectiva de máquinas de computación altamente paralelas que constan de 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, el advenimiento de la concurrencia masiva a través de arquitecturas informáticas de múltiples núcleos y muchos núcleos ha revivido 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 más tarde, 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 la transición complementario al de Clinger. [6] Esto resultó en el desarrollo completo 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, del Message Passing Semantics Group del Massachusetts Institute of Technology (MIT), realizaron un importante trabajo de implementación de software. Los grupos de investigación dirigidos por Chuck Seitz en el California Institute of Technology (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 de actor .

Se han llevado a cabo investigaciones sobre el modelo de 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 , el 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 actor adopta la filosofía de que todo es un actor . Esto es similar a la filosofía de que todo es un objeto que utilizan 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:

No existe una secuencia supuesta 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 una dirección, a veces llamada "dirección de correo". Por lo tanto, un actor sólo puede comunicarse con actores cuyas direcciones posee. Puede obtenerlas 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álculos dentro y entre 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 restricciones 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 los sistemas en el modelo de actor. Entre ellos se incluyen:

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 (ver Intentos de relacionar la semántica del actor con el álgebra y la lógica lineal ):

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:

Semántica de transmisión de mensajes

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

La controversia del no determinismo sin límites

Se podría decir que los primeros programas concurrentes fueron los controladores de interrupciones . Durante el transcurso de su funcionamiento normal, un ordenador necesitaba poder recibir información del exterior (caracteres de un teclado, paquetes de una red, etc. ). Por lo tanto, cuando llegaba la información, se interrumpía la ejecución del ordenador y se invocaba un código especial (llamado controlador de interrupciones) para colocar la información en un búfer de datos donde pudiera recuperarse posteriormente.

A principios de los años 1960, se empezaron a utilizar interrupciones para simular la ejecución concurrente 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 uno de exclusión mutua en una sola computadora. Edsger Dijkstra desarrolló semáforos y más tarde, 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ó más tarde mediante la construcción serializadora ([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 utilizaban un estado global para representar un paso computacional (generalizado posteriormente en [McCarthy y Hayes 1969] y [Dijkstra 1976], véase Ordenamientos de eventos versus estado global ). Cada paso computacional iba de un estado global del cómputo al siguiente estado global. 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 de empuje hacia abajo , incluidas sus versiones no deterministas . Dichos autómatas no deterministas tienen la propiedad del no determinismo acotado ; es decir, si una máquina siempre se detiene cuando se inicia 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 el servicio de una solicitud puede volverse ilimitada como resultado del arbitraje de la contención por recursos compartidos mientras que aún se garantiza 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 podría terminar solo 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 en el tiempo que tarda un circuito computacional llamado árbitro en establecerse (ver metaestabilidad (electrónica) ). [21] Los árbitros se utilizan en las computadoras para lidiar con la circunstancia de que los relojes de la computadora operan de manera asincrónica con respecto a la entrada desde el exterior, por ejemplo , entrada del teclado, acceso al disco, entrada de red, etc. Por lo que podría tomar un tiempo ilimitado para que se reciba un mensaje enviado a una computadora y, mientras tanto, la computadora podría atravesar 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 del dominio . [2] En el modelo de actor, no hay un estado global. [ dudoso – discutir ]

Comunicación directa y asincronía

Los mensajes en el modelo de actor no necesariamente se almacenan en el búfer. Esto fue una ruptura radical con los enfoques anteriores de los modelos de computación concurrente. La falta de almacenamiento en el búfer causó una gran cantidad de malentendidos en el momento del desarrollo del modelo de actor y todavía es un tema controvertido. Algunos investigadores argumentaron que los mensajes se almacenan en el búfer en el "éter" o el "entorno". Además, los mensajes en el modelo de actor simplemente se envían (como los paquetes en IP ); no hay ningún requisito de un protocolo de enlace sincrónico con el destinatario.

La creación de actores más las direcciones en los mensajes significa una 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íos. Por supuesto, si el remitente de una comunicación deseaba que un destinatario tuviera acceso a direcciones que el destinatario aún no tenía, la dirección tendría que enviarse en la comunicación.

Por ejemplo, un actor podría necesitar enviar un mensaje a un actor receptor del cual posteriormente 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 implemente 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 denomina reanudación (a veces también llamado marco de continuación o de pila ). Cuando el actor receptor 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.

Por lo tanto, la capacidad de los actores de 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 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.

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

No hay requisitos 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 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 llegan para que se puedan recuperar en orden FIFO . Por lo tanto, si un actor Xenvió un mensaje M1a un actor Yy luego Xenvió otro mensaje M2a Y, no existe ningún requisito de que M1llegue a Yantes de 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 envían. No proporcionar la garantía del orden de entrega permite que la conmutación de paquetes almacene paquetes en búfer, utilice múltiples rutas para enviar paquetes, reenvíe paquetes dañados y proporcione otras optimizaciones.

Por ejemplo, a los actores se les permite canalizar el procesamiento de mensajes. Esto significa que, durante el procesamiento de un mensaje M1, un actor puede designar el comportamiento que se utilizará para procesar el siguiente mensaje y, de hecho, comenzar a procesar otro mensaje M2antes de que haya terminado de procesarlo M1. El hecho de que a un actor se le permita canalizar el procesamiento de mensajes no significa que deba canalizar el procesamiento. Si un mensaje se canaliza o no es una disyuntiva de ingeniería. ¿Cómo sabría un observador externo si el procesamiento de un mensaje por parte de un actor se ha canalizado? No hay ninguna ambigüedad en la definición de un 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.

La localidad significa que, al procesar un mensaje, un actor puede enviar mensajes únicamente a las direcciones que recibe en el mensaje, a las direcciones que ya tenía antes de recibir el mensaje y a las direcciones de los actores que crea mientras procesa el mensaje (consulte Sintetizar direcciones de actores).

Además, la localidad significa 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 ubicaciones.

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] desarrollada posteriormente 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 extensa . 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 que son 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 al comportamiento. Estas obtienen aproximaciones cada vez mejores y construyen una denotación (significado) para como sigue [Hewitt 2008; Clinger 1981]:

De esta manera, se puede caracterizar matemáticamente en términos de todos sus comportamientos posibles (incluidos aquellos que involucran un no determinismo ilimitado). Aunque no es una implementación de , se puede utilizar para demostrar una generalización de la tesis de Church-Turing-Rosser-Kleene [Kleene 1943]:

Una consecuencia del teorema anterior es que un actor finito puede responder de manera no determinista con un número incontable [ aclarar ] de salidas 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 estructura de control que surgieron en el desarrollo del lenguaje de programación Planner . [ cita requerida ] 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 "el cálculo puede ser subsumido por 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 han hecho intentos de extender la programación lógica al cómputo 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 (véase Indeterminación en el cómputo 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 actores es la capacidad de los actores de cambiar de ubicación. Por ejemplo , en su tesis, Aki Yonezawa modeló una oficina postal en la que los actores clientes podían entrar, cambiar de ubicación mientras operaban y salir. Un actor que puede migrar puede modelarse teniendo 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. [ cita requerida ]

Seguridad

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

Sintetizando las direcciones de los 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 (véase Seguridad). Sin embargo, si la dirección de un actor es simplemente una cadena de bits, entonces claramente se puede sintetizar, aunque puede resultar difícil o incluso inviable 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 llegar a un actor. Dado que una URL es una cadena de caracteres, claramente 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 el mapeo. La idea es utilizar un sistema de actores para realizar el mapeo a las direcciones de actores reales. Por ejemplo, en una computadora, la estructura de memoria de la computadora 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 .

Contraste con otros modelos de concurrencia en el 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 original de procesos secuenciales comunicantes (CSP) [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 que se comunicaban mediante el paso de mensajes sincrónico basado en nombres de procesos (consulte Historia del modelo de actor y cálculos de procesos ). Las versiones posteriores de CSP abandonaron la comunicación basada en nombres de procesos a 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 y el cálculo π .

Estos primeros modelos de Milner y Hoare tenían la propiedad de un no determinismo acotado. La teoría moderna de la no determinismo (Hoare 1985 y Roscoe 2005) prevé explícitamente un no determinismo ilimitado.

Las redes de Petri y sus extensiones (por ejemplo, redes de Petri coloreadas) son como actores en el sentido de que se basan en el paso asincrónico de mensajes y en un 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 repositorios de mensajes (lugares).

Influencia

El modelo de actor ha influido tanto en el desarrollo de la teoría 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 sobre Turing, Robin Milner escribió: [25]

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

Este objetivo me impresionó, porque implica la 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 un cálculo algebraico...

Así, 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 por nombres (valores, registros, operadores, procesos, objetos) sean todas del mismo tipo; todas 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] Asimismo, Microsoft ha utilizado el modelo de actor en el desarrollo de su biblioteca de agentes asincrónicos. [27] Existen muchas otras bibliotecas de actor que se enumeran en la sección de bibliotecas y marcos de actores que se encuentra 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 concurrente y servicios web , entre las que se incluyen las siguientes:

Muchas de las ideas introducidas en el modelo de actor ahora también se están aplicando en sistemas multiagente por las mismas razones [Hewitt 2006b 2007b]. La diferencia clave es que los sistemas de agente (en la mayoría de las definiciones) imponen restricciones adicionales a los actores, que normalmente exigen que utilicen compromisos y objetivos.

Programación con actores

Existen varios lenguajes de programación que emplean el modelo de actor o alguna variación del mismo. Entre estos lenguajes se incluyen:

Primeros lenguajes de programación de actores

Lenguajes de programación de actores posteriores

Bibliotecas y marcos de actores

También se han implementado bibliotecas o marcos de actores para permitir la programación al estilo de actores en lenguajes que no tienen actores integrados. Algunos de estos marcos 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}}: Requiere citar revista |journal=( ayuda )
  2. ^ abcd William Clinger (junio de 1981). "Fundamentos de la semántica de actores". Tesis doctoral en matemáticas. MIT. hdl :1721.1/6935. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  3. ^ por Irene Greif (agosto de 1975). "Semántica de los procesos paralelos de comunicación". Tesis doctoral de la EECS. MIT. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  4. ^ de Henry Baker ; Carl Hewitt (agosto de 1977). "Leyes para la comunicación de procesos paralelos". IFIP. {{cite journal}}: Requiere citar revista |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. ^ abc Gul Agha (1986). "Actores: un modelo de computación concurrente en sistemas distribuidos". Tesis doctoral. MIT Press. hdl :1721.1/6952. {{cite journal}}: Requiere citar revista |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. Visualización de las estructuras de control como patrones de transmisión de mensajes. Journal of Artificial Intelligence. Junio ​​de 1977.
  9. ^ ab 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}}: Requiere citar revista |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) del 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}}: Requiere citar revista |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}}: Requiere citar revista |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}}: Requiere citar revista |journal=( ayuda )
  15. ^ "¿Qué es el modelo de actor y cuándo debería utilizarse?". 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 son excelentes para las aplicaciones de IoT». InfoWorld . Archivado desde el 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: desde los semáforos hasta las llamadas a procedimientos remotos . Springer. ISBN 978-0-387-95401-1.
  18. ^ Hansen, Per 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 de sistemas operativos". Comunicaciones de la 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. ^ ab Hewitt, Carl (2012). "¿Qué es la computación? Modelo de actor versus modelo de Turing". En Zenil, Hector (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 . World Scientific Publishing Company.
  22. ^ Frederick 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 computacionales en el Coloquio de lógica 1973.
  24. ^ CAR Hoare. 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á creciendo Twitter « Blog de Waiming Mok ". Waimingmok.wordpress.com. 2009-06-27. Archivado desde el original el 2021-02-05 . Consultado el 2012-12-02 .
  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). "Un avance del acto 1". MIT AI memo 625. hdl :1721.1/6350. {{cite journal}}: Requiere citar revista |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}}: Requiere citar revista |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 de 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. 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 núcleos múltiples: una mirada al lenguaje paralelo encore". Métodos formales para programación multinúcleo . Springer International Publishing: 1–56.
  38. ^ "El lenguaje del poni". Archivado desde el original el 4 de septiembre de 2018. Consultado el 21 de marzo de 2016 .
  39. ^ Clebsch, Sylvan; Drossopoulou, Sophia; Blessing, Sebastian; McNeil, Andy (2015). "Negar capacidades para actores seguros y rápidos". Actas del 5.º 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 y Andy McNeil
  40. ^ "El lenguaje P". GitHub . 8 de marzo de 2019. 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 2021-03-23 ​​. Consultado el 2017-02-01 .
  42. ^ "clase Ractor". Ruby-lang.org. Archivado desde el original el 2022-03-02 . Consultado el 2022-03-02 .
  43. ^ Carlos Varela y Gul Agha (2001). "Programación de sistemas abiertos dinámicamente reconfigurables con SALSA". Avisos de ACM SIGPLAN. Actas de OOPSLA'2001 Intriguing Technology Track . 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}}: Requiere citar revista |journal=( ayuda )
  45. ^ Philipp Haller y Martin Odersky (enero de 2007). "Actores que unifican hilos y eventos" (PDF) . Informe técnico LAMP 2007. Archivado desde el original (PDF) el 2011-06-07 . Consultado el 2007-12-10 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
  46. ^ "Guía del lenguaje Swift: concurrencia". 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". crates.io. Archivado desde el original el 2021-02-05 . Consultado el 2020-04-16 .
  48. ^ Bulut, Mahmut (15 de diciembre de 2019). «Bastion en Crates.io». Crates.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". crates.io. Archivado desde el original el 2021-05-14 . Consultado el 2021-02-28 .
  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 de Akka | @lightbend". Archivado desde el original el 22 de septiembre de 2022. Consultado el 24 de septiembre de 2022 .
  53. ^ Versión estable de Akka.NET v1.4.10 GitHub - akkadotnet/akka.net: puerto de actores de Akka para .NET., Akka.NET, 2020-10-01, archivado desde el original el 2021-02-24 , consultado el 2020-10-01
  54. ^ Apache Pekko (graduado), Apache Software Foundation
  55. ^ Srinivasan, Sriram; Alan Mycroft (2008). "Kilim: Isolation-Typed Actors for 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 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 desde el original el 2019-06-03 . Consultado el 2019-06-03 .
  61. ^ "Lanzamientos · ncthbrt/nact · GitHub". GitHub . Archivado desde el original el 2020-11-27 . Consultado el 2019-06-03 .
  62. ^ "Cambios - retlang - Concurrencia 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 - Concurrencia basada en mensajes para Java - Google Project Hosting". 14 de febrero de 2012. 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. ^ "Diseño y actores del Pulsar". 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 2021-02-05 . Consultado el 2019-06-03 .
  69. ^ "Theron – Ashton Mason". Archivado desde el original el 2019-03-31 . Consultado el 2018-08-29 .
  70. ^ "Theron - Versión 6.00.02 publicada". Theron-library.com. Archivado desde el original el 16 de marzo de 2016. Consultado el 25 de febrero de 2016 .
  71. ^ "Theron". 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 2020-12-15 . Consultado el 2019-06-03 .
  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. ^ "celluloid | RubyGems.org | el servidor de gemas de tu comunidad". RubyGems.org. Archivado desde el original el 2020-09-29 . Consultado el 2019-06-03 .
  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 · orbit/orbit · GitHub". GitHub . Consultado el 3 de junio de 2019 .
  79. ^ "QP Real-Time Embedded Frameworks & Tools - Examinar archivos en". Sourceforge.net. Archivado desde el original el 2021-02-24 . Consultado el 2019-06-03 .
  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 2020-09-15 . Consultado el 2022-05-17 .
  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 de FunctionalJava". GitHub. Archivado desde el original el 15 de enero de 2021. Consultado el 23 de agosto de 2018 .

Lectura adicional

Enlaces externos