Atlantis Blog

Programmation parallèle avec Scala et Akka [PSUG]

Lors de cette édition du 29 novembre 2010 du Paris Scala User Group (PSUG),  Dustin Whitney a évoqué son expérience de la programmation parallèle dans un projet réel, avec l’utilisation de la librairie Akka et du langage Scala. Pour cela, il a utilisé une présentation, que je connaissais déjà. Mais, comme vous le verrez, les commentaires de vive voix ne sont pas inutiles.

Akka est un framework de programmation parallèle fonctionnant sur la plateforme Java et disposant à la fois d’une API Scala et d’une API Java.

Dur, dur, la programmation parallèle

Les créateurs d’Akka pensent (et ils ont raison) que  :

• développer des applications utilisant des mécanismes de parallélisme (concurrency) est trop difficile,
• la scalabilité horizontale (scale out) est trop difficile à mettre en oeuvre,
• les mécanismes de tolérance à la panne (fault tolerance) sont trop complexes à mettre en place.

Face à ces problèmes, il faut élever le niveau d’abstraction. Et ce ne sont pas les rudimentaires threads et verrous (locks) qui vont permettrent ça.

Acteurs

Akka implémente tout d’abord un modèle de programmation fondé sur les acteurs.

Un acteur est un participant à un traitement parallèle  :

• qui ne partage rien avec les autres acteurs,
• avec lequel on communique à l’aide de messages, et qui communique également avec les autre acteurs par échange de messages,
• qui est léger du point de vue de son utilisation des ressources (notamment les threads et les processus),
• qui dispose d’une boîte aux lettres (mailbox)  dans laquelle il reçoit les messages, qu’il traite l’un après l’autre, et non simultanément.

Les messages correspondent aux données échangées avec les acteurs. Ils sont nécessairement non-mutables.

Avec les acteurs, un traitement parallélisé est donc la coordination d’une multitudes d’acteurs fonctionnant en parallèle, mais qui individuellement ne font qu’une chose à la fois. Ce paradigme simplifie donc le travail du développeur en lui évitant de gérer les accès concurrents sur une ressource partagée.

Dustin a ici présenté l’API Scala de gestion des acteurs et a vanté les vertus du modèle de programmation par acteurs.

Tolérance de panne

Akka propose des mécanismes de tolérance à la panne inspirés du langage Erlang. Ces mécanismes permettent de relancer un traitement en cas de plantage. Il faut pour cela créer des liens hiérarchique de supervision entre acteurs.

Un superviseur est un acteur responsable du démarrage, de l’arrêt et de la surveillance des acteurs fils qu’il supervise. Un superviseur peut à son tour être supervisé formant ainsi une hiérarchie de supervision. Un superviseur est responsable de maintenir ses acteurs fils en fonction et de les redémarrer si nécessaire, en cas de plantage.

Il existe deux stratégies de redémarrage en cas de plantage d’un acteur fils :

• Stratégie ‘un pour un‘ (one for one) : le superviseur redémarre uniquement l’acteur fils qui a planté.
• Stratégie ‘tous pour un‘ (all for one) : le superviseur redémarre tous ses acteurs fils.

Mémoire transactionnelle

La mémoire transactionnelle ou STM (software transactional memory) se propose de considérer la mémoire vive comme une donnée transactionnelle, de façon similaire à une base de données (begin, commit et rollback). Dans ce modèle :

• Les transactions sont retentées automatiquement en cas collision sur la donnée entre transactions.
• La mémoire utilisée par une transaction revient dans son état antérieur en cas d’annulation de la transaction (rollback).

Les transactions peuvent être imbriquées et composées.

La mémoire transactionnelle s’appuie sur la notion de référence. Une référence pointe vers une valeur qui est nécessairement un objet non-mutable. Elle présente les propriétés suivantes :

• La référence peut être mise à jour pour désigner une  autre valeur, mais uniquement dans le contexte d’une transaction.
• La mise à jour d’une référence est atomique et isolée (toutes les propriétés ACID sauf le D).
• Chaque transaction voit ses propres valeurs dans les références partagées entre transactions (isolation).
• Les transactions sont retentées s’il y a conflit sur une référence.

Pour être clair, Dustin n’a pas été super limpide sur le sujet, mais en allant faire un petit tour du coté de cette présentation sur la mémoire transactionnelle et les acteurs, les choses peuvent s’éclaircir substantiellement.

Acteurs distants

Les acteurs peuvent également être sollicités à distance (remote actor) d’un serveur à l’autre, par exemple. Les changements en termes de code sont relativement peu importants, mais il sera alors absolument capital que les messages soient sérialisables. Akka proposent également des fonctionnalités de cluster.

Les acteurs distants sont porteurs d’une promesse de scalabilité horizontale quasi-infinie. Cependant, d’après Dustin, il semble bien que le jeu n’en vaille pas toujours la chandelle en particulier pour les cas relativement simples.