Discussion :

[victor_gasgas]

Bonjour,

Je voudrais utiliser boost.msm [example], mais j'ai une question concernant le traitement d'un événement décidé au runtime :

Le problème c'est que contrairement à une machine à états finies implémentée "manuellement" oú l'événement est une une énumération dont la valeur peut être choisie au runtime car le type est connu à la compilation, pour boost.msm chaque événement est une structure/classe différente (cf. Exemple ci-dessus). Et dans ce cas ce n'est plus un valeur, mais un type de classe

En fait la question est plus généralement comment traiter un événement décide au runtime et non à la compilation ? Doit-on utiliser un switch qui appelle process_event avec le bon paramètre template ? Ou existe-t-il un meilleur design ?

Merci d'avance à tous !

[Flob90]

Bonjour,

Tu as le même problème avec une enum en réalité.

En effet le type est le même et avec des input qui seraient directement les valeurs de l'enum ça marche, sauf que c'est un cas d'IO assez spécifique et pauvre. Dès que tu vas mettre en place un IO plus complexe, tu vas te retrouver à devoir associer les input aux valeurs de l'enum, donc le problème s'est juste déplacé.

Avec une fsm décrite par mpl, tu as en effet des types différents, mais l'objectif est surtout de décrire à la compilation une machine à états et ses transitions. Elle répond à cette objectif (et l'objectif nécessite des types différents).

Pour l'utiliser en réponse à un système IO, tu pourrais le faire soit manuellement via un switch, soit en réponse à un système plus dynamique (signaux connectés à des foncteurs issues de binding sur des valeurs du bon type).

[victor_gasgas]

Merci pour ta résponse, mais j'aimerais exposer un peu plus le cas d'étude sur lequel je suis pour avoir ton avis :

Je travaille avec N tâches parrallles, dont une possède la machine à états.
Les autres tâches correspondent avec celle-ci grâce à une mailbox (assimilable à un pipe UNIX avec plus entrée pour faire simple).

Donc au travers de cette MB, je voulais faire passer une instance de l'énumération, qui correspondrait exactement à un événement de la MEF.

Alors je comprends très bien que c'est un cas très particulier, et est donc très pauvre.

Est-ce un switch qui serait le plus adapté pour mapper ces I/O sur les events ?
Quitte à me baser sur un système à base de boost.mpl ?

Merci encore !

[Klaim]

Si la reaction a l'event depends de quel est l'etat en cours, je ne vois pas le probleme. Tu as juste a t'assurer que le bon etat reagit au bon event de la bonne facon, c'est a dire pas forcement en faisant une transition. N'oublie pas aussi qu'il y a les guards pour tester si ton enum a une valeur particuliere.
Enfin, vois un FSM come une switch sophistique. Donc si le systeme est particulierement simple, avec peu d'etats, peut etre qu'un switch serait plus simple. MSM est efficace pour les cas ou tu veux le plus performant en profitant des information a la compilation. Si tu veux vraiment n'avoir qu'un type pour representer tes events, il se peut que ca soit moins interessant, mais si il y a beaucoup d'etats avec des reactions differentes, ca vaut certainemetn le coup (auquel cas, utilises les guards pour filtrer les valeur d'events).

Autre point: tu peux tout a fait faire un systeme d'events qui soit 1 type d'event par type dans un concurrent, je fais ca souvent, si tu veux je peux te montrer des exemples si tu penses que ca collerai a ce que tu veux faire. Generalement il faut un mix de queue lockfree, de map ou hash-map concurrent et d'un poil de meta-programmation.

[victor_gasgas]

Le système est entièrement connu à la compilation, mais il peut être assez complexe, il représente l'intelligence d'un robot.

En plus, utilisant du temps réel avec Linux, je dois faire attention à ne pas utiliser de syscall (l'allocation dynamique est à eviter le plus possible, donc exit vector et map, ou il faut utiliser un allocateur special, mais c'est très consommateur de temps encore) et rester le plus performant ! C'est pour ça que mon choix s'est tourné vers boost.msm !

En plus à terme j'aimerais pouvoir convertir un fichier UML (XMI) en MEF pour prototyper plus rapidement !

Mais à utiliser boost.msm j'aimerais avoir un bon design pour faire la translation entre les messages reçus à travers la MB et la MEF.

[Klaim]

Ok je vois donc est-ce que faire ta table de transition avec des guard est suffisant?

Visiblement la solution d'event a type multiple compliquerai les choses dans ton cas meme si tu peux reduire les allocations dynamiques au minimum si tu connais deja les types d'events possibles des le depart.

[victor_gasgas]

Oui je pense, surtout que la version précédente, notre MEF était simplement une combinaison d'événements et d'états, sans guards.

Par contre si on tente de passer un événement qui n'est pas reconnu, savez-vous si la MEF reste dans l'état avant le traitements, ou si une exception est lancée ? En effet, on ne pas utiliser les exceptions et on a besoin de garantir le comportement même en cas d'événement erroné.

[Klaim]

Il me semble que l'event n'est pas pris en compte si il ne remplis pas la condition du guard (quand le guard s'applique a l'event) mais il va falloir verifier dans la doc, j'utilise peu les guard.

[victor_gasgas]

Je ne parlais pas des guards, que je ne pense pas utiliser très souvent, mais au cas on demande de traiter l'événement E, mais que depuis l'état courant il n'existe aucune transition par cet événement. Mais je pense que je vais essayer par moi même voir comment se comporte boost.msm.

Maintenant pour revenir à la question d'origine je pense que vais faire un simple moyen de translation entre une instance d'énumération et la bon appel à process_event. Sûrement un switch, même si j'aurais aimé un moyen pour automatiser tout ça et m'éviter de le générer moi même