Bonjour,

Dans un système constitué de multiples tâches collaborant il est nécessaire de mettre en œuvre une communication garantissant la cohérence des données échangées entre les tâches.

L’un des mécanismes préconisés en Ada pour fournir une solution est fondé sur les types protégés.
On en trouve quelques explications par exemple ici mais le livre de Monsieur John Barnes est certainement plus didactique.

Ce mécanisme est déjà utilisé dans « Ada for Automation » notamment par exemple pour les interfaces entre la tâche principale et les tâches clients Modbus TCP ou entre la tâche principale et la tâche serveur Modbus TCP.

Pour faire court, un type protégé encapsule les données privées et protégées et doit fournir les fonctions et procédures permettant la manipulation des données. Les fonctions permettent uniquement la lecture des données protégées et comme elles ne peuvent modifier celles-ci elles peuvent être appelées de façon concurrente sans problème tandis que les procédures permettent la lecture et l’écriture des données protégées et bloquent le temps de leur exécution les appels des fonctions et procédures concurrentes.

Cependant, il se trouve que le besoin était jusque là considéré comme spécifique et cela a donc conduit à des mises en œuvre spécifiques.
Mais si l’on considère le besoin d’une façon générale on peut aboutir à une solution plus générique qui peut convenir dans une grande majorité des cas d’utilisation.
Ainsi, dans « Ada for Automation », la tâche principale est par défaut associée à une tâche périodique. Ces tâches jusque là tournaient indépendamment l’une de l’autre et j’avais remis aux calendes de les faire communiquer entre elles autrement que par variables partagées, sans gestion de la cohérence donc.

En cette fin d’année les calendes sont donc arrivées !

J’ai nommé le mécanisme « Dual Port Memory » générique par déformation professionnelle, en référence à la fameuse Dual Port Memory Hilscher dont il est souvent question dans les pages de ce site. Et aussi bien sûr parce que la similitude est bien réelle.

Vous voudrez bien vous référer au schéma ci-après pour les explications qui suivent.

Si le mécanisme est générique, les données échangées sont structurées dans des types de données propres à l’application.
Le paquetage implémentant le mécanisme générique est instancié en lui fournissant les types de données Entrées et Sorties et figure dans la partie privée du paquetage « Interface ». Entrée et Sortie sont vues ainsi par l’une des tâches, l’autre voyant bien sûr l’inverse.

Ce paquetage contient également les zones d’échanges pour les programmes utilisateur de chacune des tâches, de façon similaire aux mémoires images process, ces zones étant aussi des instances des mêmes types Entrées et Sorties.
Il contient enfin les fonctions et procédures assurant la mise à jour des zones d’E/S, ces fonctions et procédures étant appelées par les tâches en amont et aval des traitements utilisateur.

Voici la spécification du paquetage générique DPM :

Et le corps :

Pour l’exemple d’instanciation voici ci-après la spécification du paquetage réalisant celle nécessaire pour l’exemple d’interface entre la tâche principale et la tâche périodique 1.

On y trouve :

• la définition des types Entrées et Sorties,
• la définition des zones mémoire correspondantes pour la tâche principale et la tâche périodique 1,
• les procédures gérant les échanges entre les zones mémoire et les données protégées,
• et dans la partie privée, l’instance du paquetage générique.

Pour votre application, il est nécessaire d’adapter les types de données Entrées et Sorties comme vous l’avez sans doute compris.

En voici le corps :

Dans la tâche principale on rajoute les deux incantations autour de l’appel au programme utilisateur :

Et on procède de même avec la tâche périodique 1 :

Enfin, on peut jouer avec notre interface depuis la fonction principale… :

… comme depuis la fonction périodique :

Il y a également un programme de test qui permet de jouer avec cette DPM que vous trouverez dans le répertoire :

Comme ça fonctionne plutôt bien, je l’ai mis à l’épreuve un peu partout et j’ai donc pas mal bougrassé le code A4A en réorganisant les différents noyaux (kernels) afin d’en faciliter la réutilisation et l’évolution et en en rajoutant d’autres, ce dont je vous entretiendrai avec plaisir l’année prochaine.

Je vous remercie pour votre attention et vous souhaite de bonnes fêtes de fin d’année.

Cordialement,
Stéphane