Discussion :

[stephane.julien]

Bonjour,

J'ai une application qui permet de faire de la communication avec un automate. Sur ce dernier, il est possible de mettre des variables en surveillance. Lorsque la valeur de cette variable change, le driver automate me lance un événement.

L'implémentation de toute la colonne "Communication automate" compte 6 couches. Lorsque je reçois un événement de l'automate, celui-ci est intercepté par la couche tout en bas. Pour notifier le Main de cet événement, je remonte chacune de mes couches par événement.

En résumé, lors d'une notification d'un automate, j'ai 5 événements générés dans mon application pour que le main sache quelle opération faire.

Cela me met la puce à l'oreille, et je me pose la question si, au niveau performance, cela ne sera pas trop gourmand. Qu'en pensez-vous?

Merci de votre avis !

[dev01]

Bonjour.

Vous utilisez le mécanisme des evenements dotnet ? Si c'est le cas pas besoin de faire 5 evenements il suffit d'exposer l'évènement aux couches inférieures

[stephane.julien]

Oui j'utilise les événements dotNet. Le problème est que chaque couche ajoute son petit grain de sel (interpretation du protocole, ajout de valeurs mise en cache, ...). Donc l'événement de la couche inférieur n'aura aucun sens pour la couche supérieure.

Je profite également pour poser la question si la communication inter-couches se fait également comme cela dans d'autres projet? Pour ma part, c'est mon premier projet où j'ai besoin de communication dans les deux sens entre mes couches. D'habitude, je travaillais avec de simples appels de méthodes de haut en bas, mais pour ce qui est de la notification de bas en haut, c'est la seule solution que je vois...

[dev01]

Oui j'utilise les événements dotNet. Le problème est que chaque couche ajoute son petit grain de sel (interpretation du protocole, ajout de valeurs mise en cache, ...). Donc l'événement de la couche inférieur n'aura aucun sens pour la couche supérieure.

ok alors effectivement il faut générer autant d'évènements que de couche. Les évènements ne sont pas de gros consommateurs de mémoire mais par contre implique (à vérifier quand même j'ai doute ) un passage en mode noyau, ce qui as des conséquences néfaste.

Je profite également pour poser la question si la communication inter-couches se fait également comme cela dans d'autres projet? Pour ma part, c'est mon premier projet où j'ai besoin de communication dans les deux sens entre mes couches. D'habitude, je travaillais avec de simples appels de méthodes de haut en bas, mais pour ce qui est de la notification de bas en haut, c'est la seule solution que je vois...

Vous pouvez également utiliser des objet cyclique mais avec prudence . Il me semble qu'il y a un patten la dessus mais j'arrive pas à remettre un nom :-(

[stephane.julien]

implique (à vérifier quand même j'ai doute ) un passage en mode noyau, ce qui as des conséquences néfaste.

Qu'entendez-vous par le mode noyau? Et quelles sont les conséquences néfastes auxquelles vous faites allusion?

Mon application n'a pas encore de forme de déploiement, mais je pense à un service Windows ou une application console. Certaines couches sont rassemblées dans des assemblys différents, cela pour la réutilisabilité dans d'autres projets. Je ne sais pas si ça a un lien avec le mode noyau?

Vous pouvez également utiliser des objet cyclique mais avec prudence . Il me semble qu'il y a un patten la dessus mais j'arrive pas à remettre un nom :-(

Je ne connais pas ces objets cycliques. Si quelqu'un a de la doc là dessus, je suis intéressé! Ou une très brève description...

Merci pour les réponses!

[LoDev]

Les évènements ne sont pas de gros consommateurs de mémoire mais par contre implique (à vérifier quand même j'ai doute ) un passage en mode noyau, ce qui as des conséquences néfaste.

Des conséquences néfastes? Tu pourrais expliquer.

[Sphax]

Un passage en mode noyau ? ça m'étonnerait beaucoup, aprés tout un évenement .net c'est un simple appel de fonction .net. En terme de performance ben ça a un impact oui, tu fais 5 appels de fonction, mais je vois pas quoi améliorer si tu as une architecture en couche et que chaque couche doit enrichir l'évènement. Reste plus qu'à faire des tests pour voir si les perfs sont rédibitoires.

[dev01]

Un passage en mode noyau ? ça m'étonnerait beaucoup, aprés tout un évenement .net c'est un simple appel de fonction .net.

Effectivement autant pour moi.

Pour le mode noyau l'explication est la suivante : un programme tourne en mode utilisateur ( normal question de sécurité). certaine fonctions ( comme les evènement WIN32 ) doivent cependant être traités par le noyau car diffusé à l'ensemble des applications et de l'OS. On passe donc automatiquement en mode noyau pour la diffusion de cette info. En fait ce n'est pas l'application qui fait ça mais c'est l'OS qui se charge de le faire pour l'application. Toujours est-il que cette commutation est couteuse en terme de perf.

[stephane.julien]

Ok donc effectivement, pas besoin de mode noyau. J'ai déjà testé la suite de remontée des événements et ça fonctionne. Ma question portait plus sur la performance. Je ferai les tests et verrai ce que ça dit...

Merci pour votre avis. Je posterai un mess quand j'aurai fait les tests de performance de tous ces événements!