Article de reference

mannequin acteur

Le modèle d'acteurs en informatique est un modèle mathématique de calcul concurrent qui considère l' acteur comme l'élément de base de ce calcul. En réponse à un message reçu, u...

Le modèle d'acteurs en informatique est un modèle mathématique de calcul concurrent qui considère l' acteur comme l'élément de base de ce calcul. En réponse à un message reçu, un acteur peut : prendre des décisions locales, créer d'autres acteurs, envoyer d'autres messages et déterminer comment répondre au prochain message reçu. Les acteurs peuvent modifier leur propre état privé , mais ne peuvent interagir entre eux qu'indirectement par le biais de la messagerie (ce qui élimine le besoin de synchronisation par verrouillage ).

Le modèle d'acteurs a été introduit en 1973 Il a servi à la fois de cadre théorique pour la compréhension du calcul et de base théorique pour plusieurs implémentations pratiques de systèmes concurrents . Ses liens avec d'autres travaux sont abordés dans l' article « Modèle d'acteurs et calculs de processus » .

Carl Hewitt , contrairement aux modèles de calcul précédents, le modèle d'acteurs s'inspire de la physique , notamment de la relativité générale et de la mécanique quantique . Il est également influencé par les langages de programmation Lisp , Simula , les premières versions de Smalltalk , les systèmes à capacités et la commutation de paquets .

Son développement a été « motivé par la perspective de machines informatiques hautement parallèles composées de dizaines, de centaines, voire de milliers de microprocesseurs indépendants , chacun avec sa propre mémoire locale et son processeur de communication , communiquant via un réseau de communication à haute performance ». Depuis lors, l'avènement de la concurrence massive grâce aux architectures informatiques multicœurs et à nombreux cœurs a ravivé l'intérêt pour le modèle d'acteurs.

Suite à la publication de Hewitt, Bishop et Steiger en 1973, Irene Greif a développé une sémantique opérationnelle pour le modèle d'acteur dans le cadre de sa thèse de doctorat . Deux ans plus tard, Henry Baker et Hewitt ont publié un ensemble de lois axiomatiques pour les systèmes d'acteurs. Parmi les autres étapes importantes, on peut citer la thèse de William Clinger en 1981, qui introduit une sémantique dénotationnelle fondée sur les domaines de pouvoir , et celle de Gul Agha en 1985, qui développe un modèle sémantique basé sur les transitions, complémentaire à celui de Clinger. Ces travaux ont abouti au développement complet de la théorie du modèle d'acteur .

Les principaux travaux d'implémentation logicielle ont été réalisés par Russ Atkinson, Giuseppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman , Carl Manning, Tom Reinhardt, Richard Steiger et Dan Theriault au sein du groupe de recherche sur la sémantique du passage de messages du Massachusetts Institute of Technology (MIT). Les équipes de recherche dirigées par Chuck Seitz au California Institute of Technology (Caltech) et Bill Dally au MIT ont conçu des architectures informatiques qui ont permis de développer davantage le passage de messages dans le modèle. Voir Implémentation du modèle d'acteurs .

Des recherches sur le modèle d'acteur ont été menées au California Institute of Technology , au laboratoire Tokoro de l'université de Kyoto , à la Microelectronics and Computer Technology Corporation (MCC), au laboratoire d'intelligence artificielle du MIT , au SRI , à l'université de Stanford , à l'université de l'Illinois à Urbana-Champaign , à l'université Pierre et Marie Curie (université Paris 6), à l'université de Pise , au laboratoire Yonezawa de l'université de Tokyo , au Centrum Wiskunde & Informatica (CWI) et ailleurs.

Concepts fondamentaux

Le modèle d'acteurs adopte la philosophie selon laquelle tout est un acteur . Ceci est similaire à la philosophie « tout est un objet » utilisée par certains langages de programmation orientés objet .

Un acteur est une entité informatique qui, en réponse à un message qu'elle reçoit, peut simultanément :

  • envoyer un nombre fini de messages à d'autres acteurs ;
  • créer un nombre fini de nouveaux acteurs ;
  • désigner le comportement à utiliser pour le prochain message reçu.

Il n'y a pas d'ordre prédéfini pour les actions ci-dessus et elles peuvent être réalisées en parallèle.

Le découplage de l'expéditeur des communications envoyées a été une avancée fondamentale du modèle d'acteur permettant des structures de communication et de contrôle asynchrones en tant que modèles de transmission de messages .

Les destinataires des messages sont identifiés par leur adresse, parfois appelée « adresse postale ». Un acteur ne peut donc communiquer qu'avec les acteurs dont il possède l'adresse. Il peut l'obtenir à partir d'un message reçu ou si l'adresse correspond à un acteur qu'il a lui-même créé.

Le modèle d'acteurs se caractérise par une concurrence inhérente des calculs au sein et entre les acteurs, une création dynamique d'acteurs, l'inclusion des adresses des acteurs dans les messages et une interaction uniquement par transmission directe et asynchrone de messages sans restriction sur l'ordre d'arrivée des messages.

systèmes formels

Au fil des années, plusieurs systèmes formels différents ont été développés pour permettre le raisonnement sur les systèmes dans le modèle d'acteurs. Parmi ceux-ci :

Il existe également des formalismes qui ne sont pas entièrement fidèles au modèle d'acteurs en ce qu'ils ne formalisent pas la livraison garantie des messages, notamment les suivants (voir Tentatives de relier la sémantique des acteurs à l'algèbre et à la logique linéaire ) :

Applications

Le modèle d'acteurs peut être utilisé comme cadre pour modéliser, comprendre et raisonner sur un large éventail de systèmes concurrents . Par exemple :

  • Le courrier électronique ( e-mail ) peut être modélisé comme un système d'acteurs. Les comptes sont modélisés comme des acteurs et les adresses e-mail comme des adresses d'acteurs.
  • Les services Web peuvent être modélisés comme des acteurs avec des points de terminaison SOAP (Simple Object Access Protocol ) modélisés comme des adresses d'acteurs.
  • Les objets dotés de verrous ( comme en Java et C# ) peuvent être modélisés comme un sérialiseur , à condition que leur implémentation permette l'arrivée continue de messages (par exemple, en les stockant dans une file d'attente interne ). Un sérialiseur est un type d'acteur important, défini par sa disponibilité permanente pour la réception de nouveaux messages ; la réception de tout message envoyé à un sérialiseur est garantie.
  • La notation TTCN (Testing and Test Control Notation ), versions TTCN-2 et TTCN-3 , suit de près le modèle d'acteurs. Dans TTCN, un acteur est un composant de test : soit un composant de test parallèle (PTC), soit un composant de test principal (MTC). Les composants de test peuvent envoyer et recevoir des messages de partenaires distants (composants de test homologues ou interface du système de test), ces derniers étant identifiés par leur adresse. Chaque composant de test possède un arbre de comportement associé ; les composants de test s'exécutent en parallèle et peuvent être créés dynamiquement par leurs composants parents. Des constructions intégrées au langage permettent de définir les actions à entreprendre lors de la réception d'un message attendu depuis la file d'attente interne, comme l'envoi d'un message à une autre entité homologue ou la création de nouveaux composants de test.

Sémantique du passage de messages

Le modèle d'acteur concerne la sémantique de la transmission des messages .

La controverse sur le non-déterminisme illimité

On peut considérer que les premiers programmes concurrents étaient des gestionnaires d'interruptions . Lors de son fonctionnement normal, un ordinateur devait pouvoir recevoir des informations de l'extérieur (caractères saisis au clavier, paquets provenant d'un réseau, etc. ). Ainsi, lorsque ces informations arrivaient, l'exécution de l'ordinateur était interrompue et un code spécial (appelé gestionnaire d'interruptions) était exécuté pour placer les informations dans une mémoire tampon de données où elles pourraient être récupérées ultérieurement.

Au début des années 1960, les interruptions ont commencé à être utilisées pour simuler l'exécution concurrente de plusieurs programmes sur un même processeur. La ​​concurrence avec mémoire partagée a soulevé le problème du contrôle de concurrence . Initialement, ce problème était conçu comme un problème d' exclusion mutuelle sur un seul ordinateur. Edsger Dijkstra a développé les sémaphores et, plus tard, entre 1971 et 1973, Tony Hoare et Per Brinch Hansen ont développé les moniteurs pour résoudre le problème d'exclusion mutuelle. Cependant, aucune de ces solutions ne fournissait de construction de langage de programmation permettant d'encapsuler l'accès aux ressources partagées. Cette encapsulation a été réalisée ultérieurement par la construction du sérialiseur ([Hewitt et Atkinson 1977, 1979] et [Atkinson 1980]).

Les premiers modèles de calcul ( machines de Turing , postproductions, lambda-calcul , etc. ) étaient basés sur les mathématiques et utilisaient un état global pour représenter une étape de calcul (généralisé ultérieurement dans [McCarthy et Hayes 1969] et [Dijkstra 1976] ; voir « Ordres d’événements versus état global »). Chaque étape de calcul consistait à passer d’un état global à l’état global suivant. Cette approche par état global a été reprise dans la théorie des automates pour les machines à états finis et les machines à pile , y compris leurs versions non déterministes . Ces automates non déterministes possèdent la propriété de non-déterminisme borné ; autrement dit, si une machine s’arrête toujours lorsqu’elle démarre dans son état initial, alors le nombre d’états dans lesquels elle s’arrête est borné.

Edsger Dijkstra a approfondi l'approche de l'état global non déterministe. Son modèle a suscité une controverse concernant le non-déterminisme illimité (ou indétermination illimitée ), une propriété de la concurrence selon laquelle le délai de traitement d'une requête peut devenir illimité en raison de l'arbitrage des conflits d'accès aux ressources partagées, tout en garantissant que la requête sera finalement traitée . Hewitt a soutenu que le modèle d'acteurs devait assurer cette garantie de service. Dans le modèle de Dijkstra, bien que l'intervalle de temps entre l'exécution d'instructions séquentielles sur un ordinateur puisse être illimité, un programme (parallèle) initialisé dans un état bien défini ne peut se terminer que dans un nombre limité d'états [Dijkstra 1976]. Par conséquent, son modèle ne pouvait garantir le service. Dijkstra a affirmé qu'il était impossible de mettre en œuvre le non-déterminisme illimité.

Hewitt soutenait le contraire : il n’existe aucune limite quant au temps nécessaire à un circuit de calcul appelé arbitre pour se stabiliser (voir métastabilité (électronique) ). Les arbitres sont utilisés dans les ordinateurs pour gérer le fonctionnement asynchrone des horloges par rapport aux entrées externes, telles que les saisies au clavier, les accès disque, les entrées réseau, etc. Ainsi, la réception d’un message envoyé à un ordinateur peut prendre un temps illimité, et pendant ce temps, l’ordinateur peut parcourir un nombre illimité d’états.

Le modèle d'acteur présente un non-déterminisme illimité qui a été capturé dans un modèle mathématique par Will Clinger en utilisant la théorie des domaines . Dans le modèle d'acteur, il n'y a pas d'état global.des paquets IP ) ; aucune négociation synchrone avec le destinataire n'est requise.

La création d'acteurs et l'ajout d'adresses dans les messages impliquent une topologie variable.

L'évolution naturelle du modèle d'acteurs a consisté à autoriser les adresses dans les messages. Influencé par les réseaux à commutation de paquets [1961 et 1964], Hewitt a proposé le développement d'un nouveau modèle de calcul concurrent dans lequel les communications ne comporteraient aucun champ obligatoire : elles pourraient être vides. Bien entendu, si l'expéditeur d'une communication souhaitait qu'un destinataire ait accès à des adresses que ce dernier ne possédait pas déjà, l'adresse devrait être incluse dans la communication.

Par exemple, un acteur peut avoir besoin d'envoyer un message à un acteur destinataire dont il attend une réponse. Cependant, cette réponse sera en réalité traitée par un troisième acteur configuré pour la recevoir et la traiter (par exemple, un autre acteur implémentant le modèle observateur ). L'acteur initial peut alors envoyer une communication contenant le message à envoyer, ainsi que l'adresse du troisième acteur qui traitera la réponse. Ce troisième acteur est appelé reprise (ou continuation , ou encore cadre de pile ). Lorsque l'acteur destinataire est prêt à répondre, il envoie le message de réponse à l' adresse de la reprise indiquée dans la communication initiale.

Ainsi, la capacité des acteurs à créer de nouveaux acteurs avec lesquels ils peuvent échanger des communications, ainsi que la possibilité d'inclure les adresses d'autres acteurs dans les messages, donne aux acteurs la possibilité de créer et de participer à des relations topologiques arbitrairement variables les uns avec les autres, tout comme les objets dans Simula et d'autres langages orientés objet peuvent également être composés relationnellement en topologies variables d'objets échangeant des messages.

Intrinsèquement concurrents

Contrairement à l'approche précédente fondée sur la composition de processus séquentiels, le modèle d'acteurs a été développé comme un modèle intrinsèquement concurrent. Dans le modèle d'acteurs, la séquentialité est un cas particulier qui découle du calcul concurrent, tel qu'expliqué dans la théorie du modèle d'acteurs .

Aucune exigence quant à l'ordre d'arrivée des messages

FIFO ( premier entré, premier sorti). Ainsi, si un acteur Xenvoie un message M1à un acteur Yet Xenvoie ultérieurement un autre message M2à un autre acteur Y, rien n'oblige à ce que le premier message M1arrive Yavant le second M2.

À cet égard, le modèle d'acteurs reflète les systèmes de commutation de paquets qui ne garantissent pas la réception des paquets dans l'ordre d'envoi. L'absence de garantie d'ordre de livraison permet à la commutation de paquets de mettre en mémoire tampon les paquets, d'utiliser plusieurs chemins pour leur acheminement, de renvoyer les paquets endommagés et d'effectuer d'autres optimisations.

Par exemple, les acteurs peuvent enchaîner le traitement des messages. Cela signifie que, pendant le traitement d'un message M1, un acteur peut définir le comportement à utiliser pour traiter le message suivant, puis commencer le traitement d'un autre message M2avant même d'avoir terminé le traitement du premier M1. Le fait qu'un acteur puisse enchaîner le traitement des messages ne l'y oblige pas . L'enchaînement des messages est un choix technique. Comment un observateur externe pourrait-il savoir si le traitement d'un message par un acteur a été enchaîné ? La possibilité d'enchaîner les traitements ne prête pas à confusion avec la définition d'un acteur. Bien sûr, l'optimisation de l'enchaînement peut être mal implémentée dans certaines implémentations, ce qui peut entraîner des comportements inattendus.

Localité

Une autre caractéristique importante du modèle d'acteur est la localité.

La localité signifie que lors du traitement d'un message, un acteur ne peut envoyer de messages qu'aux adresses qu'il reçoit dans le message, aux adresses qu'il possédait déjà avant de recevoir le message, et aux adresses des acteurs qu'il crée pendant le traitement du message. (Voir cependant la section Synthèse des adresses des acteurs .)

La localité implique également l'absence de modification simultanée à plusieurs emplacements. En cela, elle diffère d'autres modèles de concurrence, comme le modèle des réseaux de Petri , où des jetons sont simultanément retirés de plusieurs emplacements et placés à d'autres.

Systèmes d'acteurs de composition

L'idée de composer des systèmes d'acteurs en systèmes plus grands est un aspect important de la modularité qui a été développé dans la thèse de doctorat de Gul Agha, développé plus tard par Gul Agha, Ian Mason, Scott Smith et Carolyn Talcott .

Comportements

Une innovation majeure a consisté à introduire un comportement spécifié sous forme de fonction mathématique pour exprimer l'action d'un acteur lors du traitement d'un message, notamment la spécification d'un nouveau comportement pour le traitement du message suivant. Les comportements ont fourni un mécanisme permettant de modéliser mathématiquement le partage en contexte de concurrence.

Les comportements ont également permis d'affranchir le modèle d'acteurs des détails d'implémentation, comme l'interpréteur de flux de jetons Smalltalk-72. Toutefois, l'implémentation efficace des systèmes décrits par le modèle d'acteurs requiert une optimisation poussée . Voir la section « Implémentation du modèle d'acteurs » pour plus de détails.

Modélisation d'autres systèmes de concurrence

D'autres systèmes de concurrence ( par exemple , les calculs de processus ) peuvent être modélisés dans le modèle d'acteurs en utilisant un protocole de validation en deux phases .

Théorème de représentation computationnelle

Migration

Dans le modèle d'acteurs, la migration désigne la capacité des acteurs à changer de position. Par exemple , dans sa thèse, Aki Yonezawa a modélisé un bureau de poste où des acteurs clients pouvaient entrer, se déplacer à l'intérieur pendant leurs opérations, puis sortir. Un acteur capable de migrer peut être modélisé par un acteur de position qui change lorsque l'acteur migre. Cependant, la pertinence de cette modélisation est controversée et fait l'objet de recherches.câblage dans lequel les acteurs sont physiquement connectés

  • matériel informatique comme le Burroughs B5000 , la machine Lisp , etc.
  • machines virtuelles comme la machine virtuelle Java , le Common Language Runtime , etc.
  • systèmes d'exploitation tels que les systèmes à capacités
  • signature et/ou chiffrement des acteurs et de leurs adresses
  • Synthétiser les adresses des acteurs

    Sécurité ). Toutefois, si l'adresse d'un acteur est simplement une chaîne de bits, elle peut évidemment être synthétisée, même s'il peut être difficile, voire impossible, de la deviner si cette chaîne est suffisamment longue. SOAP utilise une URL pour l'adresse d'un point de terminaison où un acteur est accessible. Puisqu'une URL est une chaîne de caractères, elle peut évidemment être synthétisée, bien que le chiffrement puisse la rendre pratiquement impossible à deviner.

    La synthèse des adresses des acteurs est généralement modélisée par un système de mappage. L'idée est d'utiliser un système d'acteurs pour effectuer ce mappage vers les adresses réelles des acteurs. Par exemple, sur un ordinateur, la structure de sa mémoire peut être modélisée comme un système d'acteurs réalisant ce mappage. Dans le cas des adresses SOAP , cela revient à modéliser le DNS et le reste du mappage d'URL .

    À comparer avec d'autres modèles de concurrence par passage de messages

    Les premiers travaux publiés par Robin Milner sur la concurrence étaient également remarquables en ce qu'ils ne reposaient pas sur la composition de processus séquentiels. Leurs travaux différaient du modèle d'acteurs car ils s'appuyaient sur un nombre fixe de processus de topologie fixe communiquant des nombres et des chaînes de caractères de manière synchrone. Le modèle original de processus séquentiels communicants (CSP) , publié par Tony Hoare, différait du modèle d'acteurs car il reposait sur la composition parallèle d'un nombre fixe de processus séquentiels connectés selon une topologie fixe et communiquant par passage de messages synchrone basé sur les noms de processus (voir l'historique du modèle d'acteurs et des calculs de processus ). Les versions ultérieures du CSP ont abandonné la communication basée sur les noms de processus au profit d'une communication anonyme via des canaux, une approche également utilisée dans les travaux de Milner sur le calcul des systèmes communicants (CCS) et le π-calcul .

    Ces premiers modèles de Milner et Hoare présentaient tous deux la propriété de non-déterminisme borné. Le CSP théorique moderne ([Hoare 1985] et [Roscoe 2005]) fournit explicitement un non-déterminisme non borné.

    Les réseaux de Petri et leurs extensions (par exemple, les réseaux de Petri colorés) ressemblent aux acteurs en ce qu'ils sont basés sur la transmission asynchrone de messages et un non-déterminisme illimité, tandis qu'ils ressemblent aux premiers CSP en ce qu'ils définissent des topologies fixes d'étapes de traitement élémentaires (transitions) et de référentiels de messages (lieux).

    Influence

    Le modèle d'acteur a exercé une influence considérable tant sur le développement théorique que sur le développement pratique des logiciels.

    Théorie

    Le modèle d’acteur a influencé le développement du π-calcul et des calculs de processus ultérieurs . Dans sa conférence Turing, Robin Milner a écrit :

    Le lambda-calcul pur ne repose que sur deux types d'éléments : les termes et les variables. Peut-on parvenir à la même concision pour un calcul de processus ? Carl Hewitt, avec son modèle d'acteurs, a relevé ce défi il y a longtemps ; il a affirmé qu'une valeur, un opérateur sur les valeurs et un processus devaient tous être de même nature : un acteur.

    Cet objectif m'a impressionné, car il implique l'homogénéité et la complétude de l'expression… Mais il m'a fallu longtemps avant de comprendre comment l'atteindre en termes de calcul algébrique…

    Dans l’esprit de Hewitt, notre première étape consiste donc à exiger que tout ce qui est désigné par des termes ou accessible par des noms — valeurs, registres, opérateurs, processus, objets — soit de même nature ; il s’agit de processus.

    Pratique

    Le modèle d'acteurs a eu une influence considérable sur les pratiques commerciales. Par exemple, Twitter a utilisé des acteurs pour assurer la scalabilité de ses services . De nombreuses autres bibliothèques d'acteurs sont répertoriées dans la section « Bibliothèques et frameworks d'acteurs » ci-dessous.

    Problèmes abordés

    Selon Hewitt [2006], le modèle d'acteur aborde les problèmes liés à l'architecture informatique et des communications, aux langages de programmation concurrents et aux services Web , notamment les suivants :

    • Évolutivité : le défi de l'augmentation de la concurrence, tant au niveau local que non local.
    • Transparence : combler le fossé entre concurrence locale et non locale. La transparence est actuellement un sujet controversé. Certains chercheurs préconisent une séparation stricte entre la concurrence locale, utilisant des langages de programmation concurrents (par exemple, Java et C# ), et la concurrence non locale, utilisant SOAP pour les services Web . Cette séparation stricte engendre un manque de transparence qui pose problème lorsqu’il est souhaitable, voire nécessaire, de passer d’un accès local à un accès non local aux services Web (voir Calcul distribué ).
    • Incohérence : l’incohérence est la norme car tous les grands systèmes de connaissances relatifs aux interactions homme-machine sont incohérents. Cette incohérence s’étend à la documentation et aux spécifications des grands systèmes (par exemple, les logiciels Microsoft Windows), qui sont elles-mêmes incohérentes.

    Nombre d'idées introduites dans le modèle d'acteurs trouvent désormais des applications dans les systèmes multi-agents pour les mêmes raisons [Hewitt 2006b 2007b]. La principale différence réside dans le fait que les systèmes d'agents (selon la plupart des définitions) imposent des contraintes supplémentaires aux acteurs, exigeant généralement qu'ils s'engagent et définissent des objectifs.

    Programmation avec des acteurs

    Plusieurs langages de programmation différents utilisent le modèle d'acteurs ou une variante de celui-ci. Parmi ces langages, on peut citer :

    Langages de programmation des acteurs précoces

    • Actes 1, 2 et 3
    • Acttalk
    • Ani
    • Cantor
    • Rosette

    Langages de programmation d'acteurs ultérieurs

    ABCL
  • AmbientTalk
  • Axoum
  • Langage d'acteur CAL
  • D
  • Dard
  • E
  • Élixir
  • Erlang
  • Fantom
  • Lueur
  • Humus
  • Io
  • LFE
  • Encore
  • Poney
  • Projet Ptolémée
  • P
  • P#
  • Langage de modélisation Rebeca
  • Reia
  • Rubis
  • SALSA
  • Scala
  • Swift
  • TNSDL
  • Bibliothèques et frameworks d'acteurs

    Des bibliothèques ou des frameworks d'acteurs ont également été mis en œuvre pour permettre la programmation par acteurs dans des langages qui ne disposent pas d'acteurs intégrés. Voici quelques exemples de ces frameworks :

    NomStatutDernière versionLicenceLangues
    exacteurApache 2.0C++20
    OtaviaApache 2.0Scala
    Gobelins-Racket Gobelins-RuseApache 2.0Arnaque, stratagème rusé
    AbstracteurApache 2.0Java
    Gobelins XcraftMITJavaScript
    RéagiApache 2.0Java
    ActeurApache-2.0 / MITRouiller
    BastionApache-2.0 / MITRouiller
    ActixMITRouiller
    AojetMITRapide
    ActeurMITJava
    Acteur4jApache 2.0Java
    ActeurApache 2.0Java
    Vert.xApache 2.0Java, Groovy, JavaScript, Ruby, Scala, Kotlin, Ceylan
    ActorFxApache 2.0.FILET
    Akka (boîte à outils) de Lightbend Inc.Apache 2.0 jusqu'à 2.6.20)Java et Scala
    Akka.NETApache 2.0.FILET
    Apache Pekko est un fork d'Akka à partir de la version 2.6.xApache 2.0Java et Scala
    DaprApache 2.0Java, .NET Core, Go, JavaScript, Python, Rust et C++
    DOTNETACTORSMIT.NET, C#, Azure Service Bus
    React.NetMIT.NET, JavaScript
    Ateji PXMPL-2C
    Processeur de boîte aux lettres F#Licence ApacheFa#
    KorusGPL 3Java
    Kilim MITJava
    ActorFoundry (inspiré de Kilim)BSDObjectif-C
    Cloud HaskellBSDHaskell
    CloudIMITATS, C/C++, Elixir/Erlang/LFE, Go, Haskell, Java, JavaScript, OCaml, Perl, PHP, Python, Ruby, Rust
    DésordreLGPL 2.1C, C++ (cluttermm), Python (pyclutter), Perl (perl-Clutter)
    Acte NLGPL 3.0.FILET
    Nact le 05/02/2021 sur la Wayback MachineApache 2.0JavaScript/ReasonML
    RetlangNouveau BSD.FILET
    Acteur JALGPLJava
    JetlangNouveau BSDJava
    Acteur HaskellNouveau BSDHaskell
    GParsApache 2.0Groovy
    OOSMOSLicence GPL 2.0 et licence commerciale (double licence)C. Compatible avec C++
    PaniniMPL 1.1Langage de programmation en soi
    PARLEMENTERGPL 2.1Python
    PéréniqueLGPL 3.0Java
    PicosMITKRL
    PostSharpFreemium.FILET
    PulsarNouveau BSDPython
    PulsarLGPL / EclipseClojure
    PykkaApache 2.0Python
    Programme anti-termitesLGPLSchéma (implémentation Gambit)
    MIT C++
    comédienMITPython
    QuasarLGPL / EclipseJava
    LibacteurGPL 2.0C
    Acteur-CPPGPL 2.0C++
    S4Apache 2.0Java
    Framework d'acteurs C++ (CAF)Licence logicielle Boost 1.0 et BSD 3 clausesC++11
    CelluloïdMITRubis
    Cadre d'acteurs LabVIEWNouveau BSDJava
    Cadres QP pour systèmes embarqués temps réelLicence GPL 2.0 et licence commerciale (double licence)C et C++
    processus de bibliothèqueApache 2.0C++
    SObjectizerNouveau BSDC++17
    rotorLicence MITC++17
    OrléansLicence MITC#/.NET
    SkynetLicence MITC/Lua
    Réacteurs.IOLicence BSDJava/Scala
    libagentsLicence de logiciel libreC++11
    Proto.ActeurLicence de logiciel libreGo, C#, Python, JavaScript, Kotlin
    FunctionalJava le 22 avril 2021 sur la Wayback MachineBSD 3-ClauseJava
    RikerLicence MITRouiller
    ComédieEPL 1.0JavaScript
    Acteurs VLINGO XOOMLicence publique Mozilla 2.0Java, Kotlin, langages JVM, C# .NET
    wasmCloudApache 2.0WebAssembly (Rust, TinyGo, Zig, AssemblyScript)
    rayonApache 2.0Python
    celluleNouvelle licence BSDPython
    acteur de goLicence MITAller
    SentoApache 2.0Common Lisp
    TarantMITTypeScript, JavaScript