Wikibrief

Modelo de actor

Editar artículo

El modelo de actor en ciencias de la computación es un modelo matemático de computación concurrente que trata al actor como el primitivo universal de 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. 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 otro trabajo se discute en el modelo de actor y los cálculos de proceso.

Contenido
  • 1 Historia
  • 2 Conceptos fundamentales
  • 3 Sistemas formales
  • 4 aplicaciones
  • 5 Semántica de paso de mensajes
    • 5.1 Controversia ilimitada del no determinismo
    • 5.2 Comunicación directa y asincronía
    • 5.3 La creación de actores más direcciones en mensajes significa topología variable
    • 5.4 Inherentemente concurrente
    • 5.5 Ningún requisito sobre el orden de llegada del mensaje
    • 5.6 Localidad
    • 5.7 Composición de sistemas de actores
    • 5.8 Comportamientos
    • 5.9 Modelado de otros sistemas de concurrencia
    • 5.10 Teorema de representación computacional
    • 5.11 Relación con la programación lógica
    • 5.12 Migración
    • 5.13 Seguridad
    • 5.14 Sintetizar direcciones de actores
    • 5.15 Contraste con otros modelos de concurrencia de paso de mensajes
  • 6 Influencia
    • 6.1 Teoría
    • 6.2 Práctica
  • 7 Problemas resueltos
  • 8 Programación con actores
    • 8.1 Lenguajes de programación de actores tempranos
    • 8.2 Lenguajes de programación de actores posteriores
    • 8.3 Bibliotecas y marcos de actores
  • 9 Véase también
  • 10 referencias
  • 11 Lecturas adicionales
  • 12 Enlaces externos

Historia

Artículo principal: Historia del modelo Actor

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. 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 fue "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, que se comunican a través de una red de comunicaciones de alto rendimiento". Desde entonces, el advenimiento de la concurrencia masiva a través de arquitecturas de computadora de múltiples núcleos y muchos núcleos ha reavivado el interés en el modelo de actor.

Siguiendo la publicación de 1973 de Hewitt, Bishop y Steiger, Irene Greif desarrolló una semántica operativa para el modelo de actor como parte de su investigación doctoral. Dos años más tarde, Henry Baker y Hewitt publicaron un conjunto de leyes axiomáticas para los sistemas de actores. Otros hitos importantes incluyen la disertación de 1981 de William Clinger que presenta una semántica denotacional basada en dominios de poder y la disertación de 1985 de Gul Agha, que desarrolló aún más un modelo semántico basado en la transición complementario al de Clinger. 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 en el grupo de semántica de transmisión de mensajes en Instituto de Tecnología de Massachusetts (MIT). Los grupos de investigación dirigidos por Chuck Seitz en el Instituto de Tecnología de California (Caltech) y Bill Dally en el MIT construyeron arquitecturas informáticas que desarrollaron aún más el mensaje que pasa en el modelo. Consulte Implementación del modelo de actor.

La investigación sobre el modelo de actor se ha llevado a cabo en el Instituto de Tecnología de California, el Laboratorio Tokoro de la Universidad de Kyoto, la Corporación de Tecnología Informática y Microelectrónica (MCC), el Laboratorio de Inteligencia Artificial del MIT, SRI, la Universidad de Stanford, la Universidad de Illinois en Urbana-Champaign, Pierre y Marie Universidad Curie (Universidad de París 6), Universidad de Pisa, Laboratorio Yonezawa de la Universidad de Tokio, Centrum Wiskunde amp; Informatica (CWI) y otros lugares.

Conceptos fundamentales

El modelo de 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;
  • designar el comportamiento que se utilizará para el siguiente mensaje que reciba.

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

El desacoplamiento del remitente de las comunicaciones enviadas fue un avance fundamental del modelo de actor que permite la comunicación asincrónica y las estructuras de control como patrones de transmisión de mensajes.

Los destinatarios de los mensajes se identifican por dirección, a veces denominada "dirección postal". Por lo tanto, un actor solo puede comunicarse con actores cuyas direcciones tiene. 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 computación dentro y entre actores, la creación dinámica de actores, la inclusión de direcciones de actor en los mensajes y la interacción solo a través del paso directo asincrónico de mensajes 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. Éstos incluyen:

También hay formalismos que no son completamente fieles al modelo del 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. Por ejemplo:

  • El correo electrónico ( correo electrónico ) se puede modelar como un sistema de actores. Las cuentas se modelan como actores y las direcciones de correo electrónico como direcciones de actores.
  • Los servicios web se pueden modelar con puntos finales del Protocolo simple de acceso a objetos ( SOAP ) modelados como direcciones de actor.
  • Los objetos con bloqueos ( p. Ej., Como en Java y C # ) se pueden modelar como un serializador, siempre que sus implementaciones sean tales que los mensajes puedan llegar continuamente (quizás almacenándose en una cola interna). Un serializador es un tipo importante de actor definido por la propiedad de que está continuamente disponible para la llegada de nuevos mensajes; se garantiza que llegará cada mensaje enviado a un serializador.
  • Prueba y notación de control de prueba ( TTCN ), tanto TTCN-2 como TTCN-3, sigue el modelo de actor bastante de cerca. 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 de pares o interfaz del sistema de prueba), identificándose este último por su dirección. Cada componente de prueba tiene un árbol de comportamiento vinculado a él; Los componentes de prueba se ejecutan en paralelo y pueden crearse dinámicamente mediante componentes de prueba principales. Las construcciones de lenguaje incorporadas permiten la definición de 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 simultáneos fueron controladores de interrupciones. Durante el transcurso de su funcionamiento normal, una computadora 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 manejador 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, las interrupciones comenzaron a usarse para simular la ejecución simultánea de varios programas en un procesador. 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, Tony Hoare y Per Brinch Hansen desarrollaron monitores para resolver el problema de la exclusión mutua. Sin embargo, ninguna de estas soluciones proporcionó una construcción de lenguaje de programación que encapsulara el acceso a los recursos compartidos. Esta encapsulación se logró más tarde mediante la construcción del serializador ([Hewitt y Atkinson 1977, 1979] y [Atkinson 1980]).

Los primeros modelos de computación ( por ejemplo, máquinas de Turing, postproducciones, el cálculo lambda, etc.) se basaron en las matemáticas y utilizaron un estado global para representar un paso computacional (luego generalizado en [McCarthy y Hayes 1969] y [Dijkstra 1976] ver Ordenaciones de eventos versus estado global ). Cada paso computacional fue de un estado global del cálculo al siguiente estado global. El enfoque de estado global continuó en la teoría de autómatas para máquinas de estados finitos y máquinas de apilamiento descendente, incluidas sus versiones no deterministas. Estos autómatas no deterministas tienen la propiedad del no determinismo acotado ; es decir, si una máquina siempre se detiene cuando 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 de estado global no determinista. El modelo de Dijkstra dio lugar a una controversia sobre el no determinismo ilimitado (también llamado indeterminación ilimitada), una propiedad de la concurrencia por la cual la cantidad de demora en atender una solicitud puede volverse ilimitada como resultado del arbitraje de la disputa por recursos compartidos al tiempo que garantiza que la solicitud eventualmente será reparado. Hewitt argumentó que el modelo de actor debería brindar 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 brindar la garantía de servicio. Dijkstra argumentó que era imposible implementar el no determinismo ilimitado.

Hewitt argumentó lo contrario: no se puede establecer un límite en cuanto al tiempo que tarda un circuito computacional llamado árbitro en establecerse (ver metaestabilidad (electrónica) ). Árbitros se utilizan en los ordenadores para hacer frente a la circunstancia de que los relojes del ordenador operan de forma asíncrona con respecto a la entrada desde el exterior, por ejemplo, la entrada de teclado, acceso a disco, entrada de red, etc. Por lo tanto, podría tomar un tiempo sin límites para un mensaje enviado a un ordenador para recibirse 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 usando la teoría del dominio. En el modelo de actor, no existe un estado global.

Comunicación directa y asincronía

Los mensajes del modelo de actor no se almacenan necesariamente en búfer. Esta fue una ruptura brusca con los enfoques anteriores a los modelos de computación concurrente. La falta de amortiguación provocó una gran cantidad de 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 búfer en el "éter" o el "entorno". Además, los mensajes en el modelo de actor se envían simplemente (como paquetes en IP ); no hay ningún requisito para un apretón de manos sincrónico con el destinatario.

La creación de actores más las direcciones en los 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 en absoluto: podrían estar vacías. 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 destinatario del que luego espera recibir una respuesta, pero la respuesta en realidad será manejada por un componente de tercer 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 incluye 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 se llama continuación o marco 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 para crear nuevos actores con los que puedan 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í, tanto como los objetos en Simula y otros lenguajes orientados a objetos también pueden estar compuestos 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 se derivaba del cálculo concurrente, como se explica en la teoría del modelo de actor.

Ningún requisito sobre el orden de llegada del mensaje

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 el orden de los mensajes de salida, un actor de cola que proporcione esta funcionalidad puede modelarlo. Un actor de cola de este tipo pondría en cola los mensajes que llegaran para poder recuperarlos en orden FIFO. Así que si un actor Xenvió un mensaje M1a un actor Y, y más tarde Xenvió otro mensaje M2a Y, no hay ningún requisito de que M1llega a Yantes M2.

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

Por ejemplo, los actores pueden 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, de hecho, comenzar a procesar otro mensaje M2antes de que haya terminado de procesarse M1. El hecho de que un actor pueda canalizar el procesamiento de mensajes no significa que deba canalizar el procesamiento. Si un mensaje se canaliza es una compensación 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 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 ocurrir 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 direcciones que recibe en el mensaje, direcciones que ya tenía antes de recibir el mensaje y direcciones de actores que crea mientras procesa el mensaje. (Pero vea Sintetizar direcciones de actores).

Además, la localidad significa que no hay cambios simultáneos en varias ubicaciones. De esta manera, se diferencia de algunos 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.

Componer 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, desarrollada más tarde por Gul Agha, Ian Mason, Scott Smith y Carolyn Talcott.

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, es fundamental comprender que 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 compromiso de dos fases.

Teorema de representación computacional

Ver también: Semántica denotacional del modelo Actor

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 que se aproxima al comportamiento. Éstos obtienen cada vez mejores aproximaciones y construyen una denotación (significado) de la siguiente manera [Hewitt 2008; Clinger 1981]:

S
{\ Displaystyle {\ mathtt {S}}}⊥SprogressionS S
{\ Displaystyle {\ mathtt {S}}}

D mi norte o t mi S≡ lim I → ∞ pag r o gramo r mi s s I o norte S I( ⊥ S)
{\ Displaystyle \ mathbf {Denote} _ {\ mathtt {S}} \ equiv \ lim _ {i \ to \ infty} \ mathbf {progresión} _ {{\ mathtt {S}} ^ {i}} (\ bot _ {\ mathtt {S}})}

De esta manera, Sse puede caracterizar matemáticamente en términos de todos sus comportamientos posibles (incluidos los 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]:

D mi norte o t mi S
{\ Displaystyle \ mathbf {denotar} _ {\ mathtt {S}}} S
{\ Displaystyle {\ mathtt {S}}}

Una consecuencia del teorema anterior es que un actor finito puede responder de forma no determinista con un número incontable 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 tratar los problemas de la estructura de control que surgieron en el desarrollo del lenguaje de programación Planner. 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 cómputo concurrente ).

Sin embargo, se intentó extender la programación lógica a la computación concurrente. Sin embargo, Hewitt y Agha [1991] afirmaron que los sistemas resultantes no eran deductivos en el siguiente sentido: los pasos computacionales de los sistemas de programación lógica concurrente no siguen deductivamente de los pasos anteriores (ver Indeterminación en 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.

Migración

La migración en el modelo de actor es la capacidad de los actores para cambiar de ubicación. Por ejemplo, en su disertación, Aki Yonezawa modeló una oficina de correos a la que los 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.

Seguridad

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

Sintetizar 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, la seguridad se puede utilizar 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 usa una URL para la dirección de un punto final donde se puede contactar 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 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 la memoria de la computadora se puede modelar como un sistema de actores que hace el mapeo. En el caso de las direcciones SOAP, está modelando el DNS y el resto de la asignación de URL.

Contraste con otros modelos de simultaneidad de paso de mensajes

El trabajo publicado inicial de Robin Milner sobre la concurrencia también fue notable porque no se basó en la composición de procesos secuenciales. Su trabajo se diferencia del modelo de actor porque se basa en un número fijo de procesos de topología fija que comunican números y cadenas mediante comunicación sincrónica. El modelo original de procesos secuenciales de comunicación (CSP) 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 se comunicaban mediante el paso de mensajes sincrónico basado en nombres de procesos. (ver 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 la propiedad de un no determinismo acotado. La CSP moderna y teórica ([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 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 repositorios 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ó:

Ahora, el cálculo lambda puro se construye con solo 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 actor, respondió a este desafío hace 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 la integridad de la expresión... Pero pasó mucho antes de que pudiera ver cómo alcanzar el objetivo en términos de cálculo algebraico...

Entonces, en el espíritu de Hewitt, nuestro primer paso es exigir que todas las cosas denotadas por términos o accesibles por 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 la escalabilidad. Además, Microsoft ha utilizado el modelo de actor en el desarrollo de su biblioteca de agentes asincrónicos. Hay muchas otras bibliotecas de actores enumeradas en la sección de bibliotecas y marcos de actores a continuación.

Problemas resueltos

Según Hewitt [2006], el modelo de actor aborda problemas en la arquitectura de la computadora y las comunicaciones, los lenguajes de programación concurrentes y los servicios web, incluidos los siguientes:

  • Escalabilidad : el desafío de escalar la simultaneidad tanto a nivel local como no local.
  • Transparencia : salvar el abismo entre la concurrencia local y no local. La transparencia es actualmente un tema controvertido. Algunos investigadores han abogado por una separación estricta entre la concurrencia local usando lenguajes de programación concurrentes (por ejemplo, Java y C # ) de la concurrencia no local usando 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 de múltiples agentes por estas 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, por lo general requieren que hagan uso de compromisos y metas.

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 para actores tempranos

  • Acto 1, 2 y 3
  • Acttalk
  • Y yo
  • Cantor
  • Rosetón

Lenguajes de programación de actores posteriores

Bibliotecas y frameworks 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 incorporados. Algunos de estos marcos son:

Nombre Estado Último lanzamiento Licencia Idiomas
Reaccionó Activo 2021-09-05 Apache 2.0 Java
Acteur Activo 2020-04-16 Apache-2.0 / MIT Oxido
Bastión Activo 2020-08-12 Apache-2.0 / MIT Oxido
Actix Activo 2020-09-11 MIT Oxido
Aojet Activo 2016-10-17 MIT Rápido
Actor Activo 2017-03-09 MIT Java
Actor4j Activo 2020-01-31 Apache 2.0 Java
Actr Activo 2019-04-09 Apache 2.0 Java
Vert.x Activo 2018-02-13 Apache 2.0 Java, Groovy, Javascript, Ruby, Scala, Kotlin, Ceilán
ActorFx Inactivo 2013-11-13 Apache 2.0 .NETO
Akka (caja de herramientas) Activo 2019-05-21 Apache 2.0 Java y Scala
Akka.NET Activo 20-08-2020 Apache 2.0 .NETO
Remact.Net Inactivo 2016-06-26 MIT .NET, Javascript
Ateji PX Inactivo ? ? Java
czmq Activo 2016-11-10 MPL-2 C
F # MailboxProcessor Activo igual que F # (biblioteca central incorporada) Licencia Apache F#
Korus Activo 2010-02-04 GPL 3 Java
Kilim Activo 2018-11-09 MIT Java
ActorFoundry (basado en Kilim) Inactivo 2008-12-28 ? Java
ActorKit Activo 2011-09-13 BSD C objetivo
Cloud Haskell Activo 2015-06-17 BSD Haskell
CloudI Activo 2021-05-27 MIT ATS, C / C ++, Elixir / Erlang / LFE, Go, Haskell, Java, Javascript, OCaml, Perl, PHP, Python, Ruby
Desorden Activo 2017-05-12 LGPL 2.1 C, C ++ (cluttermm), Python (pyclutter), Perl (perl-Clutter)
NAct Inactivo 2012-02-28 LGPL 3.0 .NETO
Nact Activo 2018-06-06 Apache 2.0 JavaScript / ReasonML
Retlang Inactivo 2011-05-18 Nuevo BSD .NETO
JActor Inactivo 2013-01-22 LGPL Java
Jetlang Activo 2013-05-30 Nuevo BSD Java
Haskell-Actor ¿Activo? 2008 Nuevo BSD Haskell
GPars Activo 2014-05-09 Apache 2.0 Groovy
OOSMOS Activo 2019-05-09 GPL 2.0 y comercial (licencia dual) C. compatible con C ++
Panini Activo 2014-05-22 MPL 1.1 Lenguaje de programación por sí mismo
PARLAMENTAR ¿Activo? 2007-22-07 GPL 2.1 Pitón
Peernetic Activo 2007-06-29 LGPL 3.0 Java
Picos Activo 2020-02-04 MIT KRL
PostSharp Activo 2014-09-24 Comercial / Freemium .NETO
Pulsar Activo 2016-07-09 Nuevo BSD Pitón
Pulsar Activo 2016-02-18 LGPL / Eclipse Clojure
Pykka Activo 2019-05-07 Apache 2.0 Pitón
Esquema de termitas ¿Activo? 2009-05-21 LGPL Esquema (implementación de Gambito)
Theron Inactivo 2014-01-18 MIT C ++
dramático Activo 2020-03-10 MIT Pitón
Quásar Activo 2018-11-02 LGPL / Eclipse Java
Libactor ¿Activo? 2009 GPL 2.0 C
Actor-CPP Activo 2012-03-10 GPL 2.0 C ++
S4 Inactivo 2012-07-31 Apache 2.0 Java
Marco de actor de C ++ (CAF) Activo 2020-02-08 Licencia de software Boost 1.0 y 3 cláusulas BSD C ++ 11
Celuloide Activo 2018-12-20 MIT Rubí
Marco de trabajo de actor de LabVIEW Activo 2012-03-01 SLA de National Instruments LabVIEW
Biblioteca de LabVIEW Messenger Activo 2021-05-24 BSD LabVIEW
Orbita Activo 2019-05-28 Nuevo BSD Java
Marcos de QP para sistemas integrados en tiempo real Activo 2019-05-25 GPL 2.0 y comercial (licencia dual) C y C ++
libprocess Activo 2013-06-19 Apache 2.0 C ++
SObjectizer Activo 2020-05-09 Nuevo BSD C ++ 11
rotor Activo 2020-10-23 Licencia MIT C ++ 17
Orleans Activo 2021-09-03 Licencia MIT C # /.NET
Skynet Activo 2020-12-10 Licencia MIT C / Lua
Reactores.IO Activo 2016-06-14 Licencia BSD Java / Scala
libagents Activo 2020-03-08 Licencia de software libre C ++ 11
Proto.Actor Activo 2021-01-05 Licencia de software libre Ir, C #, Python, JavaScript, Java, Kotlin
FunctionalJava Activo 2018-08-18 BSD de 3 cláusulas Java
Riker Activo 2019-01-04 Licencia MIT Oxido
Comedia Activo 2019-03-09 EPL 1.0 JavaScript
vlingo Activo 2020-07-26 Licencia pública de Mozilla 2.0 Java, Kotlin, pronto.NET
wasmCloud Activo 2021-03-23 Apache 2.0 WebAssembly (Rust, TinyGo, Zig, AssemblyScript)
rayo Activo 27-08-2020 Apache 2.0 Pitón

Ver también

Referencias

Otras lecturas

enlaces externos

  • Hewitt, Meijer y Szyperski: The Actor Model (todo lo que querías saber, pero temías preguntar) Microsoft Channel 9. 9 de abril de 2012.
  • Java funcional : una biblioteca de Java que incluye una implementación de actores concurrentes con ejemplos de código en Java estándar y estilo BGGA de Java 7.
  • ActorFoundry : una biblioteca basada en Java para la programación de actores. La conocida sintaxis de Java, un archivo de compilación de hormigas 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 la programación de actores.
  • Akka - biblioteca basada actor en Scala y Java, desde Lightbend Inc..
  • GPars : una biblioteca de simultaneidad 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 el flujo de datos de grano grueso y las tareas de canalización".
  • ActorThread en C ++ 11 : plantilla base que proporciona la esencia del modelo de actor sobre hilos desnudos en C ++ 11 estándar
Contactos: mail@wikibrief.org
El contenido está disponible bajo la licencia CC BY-SA 3.0 (a menos que se indique lo contrario).