Facebook EmaiInACirclel
Développement front-end, back-end

Modèles de traitement, les acteurs font leur cinéma

PentaGuy
PentaGuy
Blogger

J’entame avec ce texte une nouvelle série d’articles pour cet été qui concernera les modèles de calcul et de traitement disons inhabituels. L’objectif est de découvrir, d’expliquer et de discuter les nombreuses alternatives au modèle de multithreading synchrone souvent considéré comme indépassable mais qui, en pratique, pose des problèmes de fiabilité et de scalabilité.

Le premier modèle alternatif de traitement que nous allons évoquer est le modèle d’acteurs. Ce modèle a été utilisé tout d’abord comme modèle théorique pour obtenir des résultats mathématiques sur le calcul concurrent et sur les modèles basés sur le traitement d’événements.

Explications

Le modèle d’acteur est semblable au modèle objet en ce sens qu’il est fortement inclusif : tout est acteur. Une différence majeure existe cependant. Alors que, de façon inhérente, le modèle d’objet est séquentiel, le modèle d’acteur est d’abord conçu pour modéliser les traitements concurrents.

Un acteur est donc, à l’instar d’un objet, une unité de calcul qui reçoit des messages. La différence majeure survient lorsque l’on décrit le comportement générique de l’acteur. A la réception d’un message, un acteur doit et ne peut exécuter de façon concurrente que les actions suivantes : envoyer un message vers un nombre fini d’acteurs, instancier un nombre fini d’acteur, indiquer le comportement à adopter lors de la réception du prochain message. Nous verrons qu’en pratique, cette liste se complète avec d’autres actions, plus concrètes.

En couplant un modèle d’acteur avec un système asynchrone de passage de messages, il est alors possible de réaliser un découplage total entre acteurs. Dans cette situation, un mécanisme d’adressage des acteurs est néanmoins requis.

Il faut garder à l’esprit que le modèle d’acteurs est avant tout un modèle. Avant de servir à concevoir des architectures de traitement, sa principale utilisation était de modéliser des systèmes existants pour mieux les comprendre, les analyser et en tirer des résultats formels.

Critiques

Le principal avantage qu’offre le modèle d’acteur par rapport disons à un modèle de threads (processus légers) est l’isolation des états. L’état interne d’un acteur y est isolé et le modèle interdit son partage. De ce fait, il n’y a aucun besoin de primitives de synchronisation antre acteurs sauf à vouloir accéder à une ressource et changer son état en tant qu’effet de bord transactionnel (écrire dans un fichier, mettre à jour une table de base de données).

A l’instar du modèle de threads, le modèle d’acteurs pose le problème du non-déterminisme de l’envoi et de la réception des messages par les acteurs. Cet aspect non-déterministe est une propriété émergente du système d’acteurs et ses conséquences sont nécessairement néfastes : manque de visibilité sur le traitement global, gestion de la mémoire dévolue aux messages en attente, effets de bord inattendus. Il faut rappeler que le modèle de threads connaît les mêmes problèmes de non-déterminisme, problème qui sont généralement résolus par de la synchronisation et de l’ordonnancement de tâches au détriment de la scalabilité et de la performance perçue.

En pratique

Si le modèle d’acteur a été et reste à la fois un sujet de recherche académique et un outil de description formelle en informatique fondamentale, il a été aussi utilisé comme paradigme dans la conception de langages et de frameworks destinés à l’implémentation de modèles de traitements concurrents.

Il faut comprendre qu’un modèle d’acteur ne concurrence pas (le jeu de mots est fortuit) les modèles de programmation concurrente que sont les processus, les threads ou les coroutines. Il permet de structurer une application qui utilise l’un ou l’autre de ces modèles en imposant des contraintes d’architecture et de programmation.

L’exemple le plus abouti que le modèle d’acteur théorique a permis de concevoir est certainement le langage Erlang, conçu par Ericsson à la fin des années 80 et rendu disponible en sources ouvertes dès 1998. Erlang est avant tout un langage dont le paradigme est la fonction (il s’agit d’un langage dit fonctionnel) mais dont le modèle d’exécution s’inspire largement du modèle d’acteur en ce sens qu’il est organisé autour de processus légers évoluant au sein d’une machine virtuelle et s’échangeant des messages sur des canaux asynchrones sans partage d’état. Avec Erlang, le paradigme fonctionnel a montré qu’il résolvait le défaut principal du modèle d’acteur : le non-déterminisme grâce à l’absence totale d’effets de bord.

Divers langages génériques ont acquis des frameworks qui implémentent le modèle d’acteurs en utilisant le paradigme principal du langage (les objets le plus souvent) en restant compatibles avec les modèles de concurrence qu’ils offrent. On peut citer Akka pour le langage Java et Pulsar pour Python. Depuis récemment, on constate un regain d’intérêt pour le modèle d’acteur dans le domaine des applications massivement distribuées avec un framework pour C# et .NET publié par Microsoft et appelé Orléans. On se devait d’en parler ici.

De manière générale, le choix d’un framework d’acteur pour un langage doit obéir à certains critères. Outre le langage d’implémentation, il est crucial de se poser la question de la localité et de la non-localité des acteurs qui se traduit pratiquement par le fait qu’il existe au moins deux protocoles pour passer un message d’un acteur à un autre selon qu’ils s’exécutent sur la même machine ou pas. Si vous désirez concevoir une application distribuée, il vous sera recommandé de n’avoir qu’un seul protocole adapté à la fois aux communications locales (interprocessus) et aux communications globales (inter-machines). La même question se pose si votre framework dispose d’un registre d’acteurs. Ce registre est-il global ou local ? On se rend compte qu’on se pose les mêmes questions qu’au moment de mettre en œuvre une architecture de services asynchrones qui ne repose pas sur la pile de protocoles Internet (HTTP/TCP/IP+DNS). Ce n’est pas un hasard, le modèle d’acteurs partage des caractéristiques communes avec les architectures de services et nous allons en reparler. D’ici là, profitez de l’été et si vous souhaitez aller plus loin sur ces thématiques, profitez de nos rendez-vous de l’été !


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *